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!

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.

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!

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.

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.

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.

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.