Accessibility Field Notes

Communis’ site for the Environment Agency’s SMURF Project website has been awarded the Special Award for Innovation at the Visionary Design Awards presented by the National Library for the Blind.

Held at the Russell Hotel in London on 2 March 2006, the Visionary Design Awards recognise organisations that have worked to make their websites easily accessible to blind and partially sighted people across the UK. After extensive testing by the NLB’s team of judges, seven awards were presented to winners chosen from a list of over 100 websites nominated by visually impaired people. This year’s awards were presented by Robert Llewellyn, star of Red Dwarf.

Communis designed the Smurf website http://www.smurf-project.info/, for a three year partnership project led by the Environment Agency. Offered in seven languages (English, French, German, Gujarati, Punjabi Urdu and Bengali), it describes the issues facing the River Tame and includes project reports, maps and information.

The site includes access to the WebSMURF system, a cut down version of the full desktop SMURF System that was developed for the SMURF project. People can use WebSMURF to find out information about the rivers Tame and Rea in the West Midlands in their browser without any special computer programs.

Communis are particularly proud to be recognised as innovation leaders in the area of providing GIS information in an accessible way, using a mixture of cutting-edge techniques to make Macromedia Flash movies more accessible, as well as presenting geographic information without using maps.

Had an interesting conversation with Google code research the other day, regarding their fascinating analysis of tag usage on websites. In December 2005 they analysed a sample of slightly over a billion documents, extracting information about popular class names, elements, attributes, and related metadata. Hours of fun.

I wanted to know how many pages in Google’s billions of indexed pages used no headers at all. Headers are an important accessibility issue. The Opera browser, for example, allows you to hop from header to header using the W and S keys (invaluable for keyboard-only users), and screenreaders such as JAWS allow you to bring up a list of all headers on a page and jump to them.

The redoubtable Ian Hickson answered as follows:

<h1> is used on about 25% of pages, <h2> on about 16% of pages, and <h3> on about 12%. (It’s possible that those 16% of <h2>s have no overlap with the 25% of <h1>s, or it’s possible that they are a complete subset, or anywhere in between.)

Three quarters of web pages out there don’t even have a <h1>? Looks like we still have a long way to go to open up the web to everybody…

Poor contrast between text and background is one of the most common accessibility problems on websites, and one of the hardest to instantly diagnose. If you have normal vision, a mid grey on a white background may be perfectly readable, and it is often used to colour, for example, copyright information or links to privacy policies etc. For someone with a vision impairment, however, it can be impossible to read. As a general rule, the palest grey recommended for a white (#ffffff) background would be #797979 (this fails the W3C algorithm put passes the HP one — palest grey on a white background allowable under W3C guidelines is #585858).

It isn’t just greys, of course. Any colour you are using against another background needs to have sufficient contrast for vision impaired users. The W3C have developed algorithms to help choose contrasting hues and brightnesses, as have Hewlett Packard, and Jez Lemon has helpfully provided a contrast analyser based on these algorithms.

You may be dolefully considering picking through your stylesheets with a fine-tooth comb to work out foreground and background colours, but there is a quicker way. The excellent ColorZilla firefox extension gives you a handy pipette tool for checking colours. Go to your Firefox extensions (Tools > Extensions > Get more extensions) and search for the latest version of Colorzilla.

Happy colouring!

This unusually helpful Microsoft article about IE text sizes is required reading for pixel-perfect elastic designs.

An interesting post on Slashdot about browser share suggests that around 85% visits to the BBC homepage over a week in September were made by browsers identifying themselves as Internet Explorer. Firefox has a respectable 9.7% share of visits.

A couple of caveats apply, however. Firstly there are automated web crawlers out there (’bots’) that identify themselves as Internet Explorer. Secondly, there is a likely correlation between experienced web users and Firefox users, and also between experienced web users and users who bookmark straight into a site rather than entering via the home page. Nevertheless, both of these considerations would put the real IE-usage figure lower and Firefox/Safari/Opera users higher.

Although the figures are neither robust nor formally endorsed by the BBC (the figures come from a BBC employee’s blog), they certainly emphasise the increasing importance of such next-generation browsers. We await further developments with interest.

Related Article: Reach More People.

Some recent user testing of ours has suggested some ways to further improve the way we implement skip links.

Unlike many others, our recommended method of implementing skip links ensures that all keyboard users ’see’ the skip link, as it appears visually on screen when a user tabs to it, and is of course read out by screen readers. The problem is this — although they find it, many web users simply do not understand what a skip link does, let alone how to use one.

Our user testing suggests that (as ever) clearer instruction is the way forward, at least until users get more familiar with skip links.

Example: Instead of the text of the link reading Skip to Main Content, have it read Skip to Main Content — press enter to activate.

Having enticed the user into pressing enter and trying the skip link out, the next step is to ensure that the user knows what has happened to their keyboard focus. A previous suggestion of using the text Bookmark: Main Content can cause some confusion, with users thinking that pressing enter would bookmark the page. So, at the risk of incurring the wrath of those that like everything short and sweet, try this:

Example: Instead of using the word Bookmark, have the target of the skip link read Start of main content: read on from here or press tab to access the next link.

Now, I can already hear sharp intakes of breath: “That text is far too long! Surely users prefer something short and neat, it looks so much better on the screen and what about those poor screenreader users who have to listen to it on every page”. Well, the fact is that without clear instruction users will not use the link at all (no, before you ask, they hardly ever read that accessibility page you carefully drafted, and when they do they probably do not understand it, but that is a story for another post…). Let’s take these points one at a time:

1. as the skip link and its target are only on screen when in use they do not take up precious screen real estate;
2. once a user has figured out how the skip link works they will often not read what the link text says. Instead, they will just see/hear the start of the link, activate it and be on their way. Our testing suggests this is equally as true of screen reader users as it is fully-sighted keyboard users.

We will be trying this out over the next few months and let you know any feedback we get, in the meantime any comments are welcome!

Our implementation of the Incident Decision Tree went live today. It’s a tool for NHS managers and senior clinicians to follow a decision-making pathway after certain types of incidents occur in the (UK) National Health Service.

Communis were invited to transform a CD-ROM kiosk application (containing content for the secondary healthcare sector) into a database-driven content-managed web application in NPSA house style that offers tailored advice to a whole range of different health care settings. By designing for all browsers, we can reach much much more of the NHS, using IE-only features (such as ActiveX based strong encryption on the client side) in an additive way. But it’s the on-screen flowchart layout, achieved using CSS, and avoiding the need for embedded images, that we’re particularly proud of.

The site is out for a six month working pilot consultation, with feedback requested from over 400 stakeholder bodies. Comments on its accessibility, as well as on the structure and content from a health care professional’s perspective, are most welcome.

Within the last few weeks, Macromedia released Studio 8, including All indications are that it’s Flash which has received the biggest overhaul, with relatively minor evolution in Coldfusion 8.

But will it be more accessible? Well, there’s no mention of accessibility in the flash Flash intro <sigh>, but… Macromedia’s own accessibility blog, which had been looking a little tired lately, is back with a vengance, and we are promised something to prolong hair life of any accessible Flash developers out there - finally we have support for partial reading orders. Required reading.

All quite promising really, though even some minor usability improvements to the authoring environment itself too would be most welcome, from me at least!

More here when we know it.

We are now fairly certain that we have the perfect skip link implementation, after much discussion and testing. There are several problems that may be found in skip link implementations.

The skip links themselves

Most problems here derive from the fact that many designers like to hide their skip links. Problematic implementations of this include:

1. Hidden too well. Use of display: none or visibility: hidden, both of which hide the links from all users, including screen reader users.
2. Completely non-visual implementation. Any method that doesn’t show the skip link itself when it has keyboard focus. Skip links are meant to be for keyboard users, both sighted and non-sighted. Hiding a skip link from all but screen reader users is therefore a no-no.
3. CSS relative movement vertically. This is where a developer styles the skiplink with CSS such that it is moved upwards by a large number of pixels sufficient to take it off-screen, and move it back down when it receives keyboard focus (defined using :focus and :action pseudoclasses, the latter for IE) so that sighted keyboard users get the benefit. All very well, but some versions of Window Eyes just lose track of it completely. Stick to horizontal movement.
4. NS7.1 crash. Combining absolute AND relative horizontal movement AND moving the link off-screen. This mysteriously crashes Netscape 7.1. Use any two of the three.

Hitting the Target

So that’s a few no-nos for the link itself, but the next set of hassles surround the target.

1. Link targets with no content. Contentless anchor elements are ignored by JAWS and several other browsers and screenreaders. Still some aesthetic debate about whoat to put in the target anchor. A header? Yes, if there is a suitable one and you’re happy to style around confusions of coloring it as a link rather than text, and your fix of the IE focus bug (see below) allows it. A single pixel gif? Ick. OK, what about the text ‘Main content begins:’? Hmmm, rather redundant for a screenreader user who has just clicked a skip link of ’skip to main content’. This is a question best answered by user testing, I think.
2. The IE keyboard focus bug. Nasty one this. If you are a regular keboard user with IE, you will have noticed that many in-page links will move the viewport, but the keyboard focus remains on the skiplink rather than moving to the target. This means that as soon as you press the tab key after skipping, you are popped back up the to the link that immediately follows the skip link. Deeply annoying. Jim solved it by using a target in a table. Not great mark-up, however, so we kept going. I realised that we could also fix the bug by putting the target in a div with an explicit, positive width or height (e.g. 100%, 1px, 20em but NOT auto or 0). This means that you can stick your target (e.g. the text ‘Main Page Content’) in a div with a width or 1px, a height of 1px, a float of right and an overflow of hidden, you have a target that works with pretty much everything (or, at least, everything we tested it on, which was a pretty good cross section of browsers and screen readers old and new). Terrence Wood suggested a formal explanation, that
   

   Using the keyboard IE6 will focus to the closest div or span element that is the parent of a target - either an element with an id, or a named anchor - where the div or span ‘hasLayout’ property is set to true. The div or span may itself contain the id being targeted. It appears that div and span are the only elements that receive focus via this method.

   Authors can set ‘hasLayout’ to true a number of ways (see MS’s
   documentation). The most common method, used by CSS authors to clear floats, is to set the element height at 1%, or by setting the width to any value as already noted.

   As a final note, in IE6 with a strict DTD, width and height do not apply to inline elements. Thus, if you want to use a span instead of a div, make sure that it is displaying as a block either by setting the display explicitly to block or inline-block or by floating it left or right.

Thanks are due to Jim Thatcher, Terrence Wood, Steve Faulkner, Mike Cherim for valuable discussion and testing.

The profile of accessibility barriers for older users is getting raised at the moment, with revisions to W3C WAI documents to mention aging specifically, and also work such as OlderWiserWired. It’s hardly rocket science, but it’s about time design was approached from a more general ‘accessibility’ point of view, challenging the depressingly popular misconception that accessibility is only an issue for blind users.