Accessibility Field Notes

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.

Good news for all you who, like us, have been tearing their hair out trying to get variously flaky assistive technologies to recognise basic semantic mark-up. And don’t get us started on Flash. Lets hope that Gez and co manage to prod some serious accessible-technology-vendor-buttock and get some standards recognised.
Good luck, guys.

Youch. Well, a week of concussion meant that Liam missed last Friday’s WAI Education and Outreach (EO) group meeting, but he’s now back at his desk, if a little bruised. Mountainboarding has a longer learning curve than he expected. He’s currently working as part of the WAI EO ‘Before and After Design’ task force to build a bad site; it’s to demonstrate poor practice and the process of bringing it up to standard. It’s actually very hard to design badly on purpose - We’re having to write pages properly and then break them! Designs are still internal at the moment - will post a link as soon as it’s public.

Those of you paying attention to the last post may have linked through to Aaron Leventhal’s accessible dhtml technology preview, which has some tasty widgets for mozilla browsers. You’ll need to install a recent nightly build of Firefox to see them in action.

We were very pleased to see that GW Micro’s next version of Window Eyes is to support Firefox 1.1. Would be nice to see Freedom Scientific do the same.

We’re busy working with Invention Media get their .Wow web content management system (and more…) to near-as-darn-it AAA accessibility. Quite a big piece of work, involving a wholesale move from tables to CSS-based layout. We have been most impressed at the improvement in rendering speed of the pages, even on a fast machine - CSS wins hands down over table-based layout. We’re nearly there, now, and there are some interesting sites going up on .Wow over the coming months. More news as it comes in.

While up to our elbows in Coldfusion, we have been giving Content Management some idle thought. Good WCM can ensure a reasonable degree of accessibility, without a great deal of knowledge on the part of content providers (apart from a quick tutorial on alt text equivalence, perhaps).

It is very difficult, however, to find useful vendor-independent advice on selecting a CMS. A couple of interesting reports shed some murky light on the subject - a rather expensive CMS report from CMSWatch, and a free CMS report from Forrester-Wave. Oddly, neither report features with Broadvision… maybe broadvision never made it big in the states. Most of the usual suspects are in there though, Interwoven, Documentum and Stellent for you ECM fans, and Tridion, and FatWire both make good showings in the F-W report.

Well the first thing we note is that the Blogger templates on offer could do with a little sprucing up, accessibility-wise. Admittedly we’re likely to be a little more pedantic than the average designer, but a skip-link wouldn’t go amiss. For now, however, it will do. It’s pretty well-structured, with good use of headings and links to make navigation fairly straightforward for screen-reader users.