Screen Readers and Source Ordering

Allow me to share with you this link to Web Usability a web site in Australia devoted to, well, web usability.

Anyways, I’ve been working on a redesign for Bridgewater State College and the roll-out happens two weeks from today. Of course I’ll be tweaking the hell out of it every day up until launch because… well nothing’s ever really finished when it comes to a web site, is it?

We started taking feedback on the design based on a preview that’s available to anyone browsing from on-campus. The topic of accessibility came up from one user’s comments with regards to screen readers and so I set about revisiting some concepts I had developed early on for the design when it comes to screen readers.

First thing’s first: “skip links” (skip to nav, skip to content) that are hidden with screen media only stylesheets DO NOT NECESSARILY WORK. As it turns out screen readers do.. amazingly… just that. They read the screen. So if your user has, say, IE 7 or Firefox rendering the page, those screen media elements are being applied and the skip links are hidden.

Specialty applications that browse websites for visually impaired users will probably pick these links up, but the point is not all screen readers will!

The result is to either show these links or make sure your site is easy to navigate for blind users. A simple test here is to just use the tab key and see in what order links are accessed.

Originally the layout I had designed was source-ordered. But after this simple tab-test I found that the navigation elements were the last thing to be accessed. This means a user with a screen reader and Firefox wouldn’t see the navigational elements of the website until they got to the very end. Not at all a good thing.

So I’ve removed the source ordering. And, honestly, doing that feels better from a semantic standpoint as well. Index before content – like books.

Yes, I could have used the TABINDEX property, but it just wouldn’t be feasible with how the template is used and how department managers update the web site.

Anyways, the point here is that source-ordered layouts might not be the most accessible thing in the world.

CSS-based drop-down menus are another problem. Try accessing your drop-down menu using just your tab key. YOU CAN’T! Unless your mouse is set to automatically position itself over a link you’ve selected using tab the link never enters the hover state and so all those :HOVER pseudoclass rules are ignored.

What about :FOCUS?

That works, for the first link. You tab over to the link and you see the drop-down menu. But as soon as you hit tab again to go to the first link in the sub-menu your menu disappears. Why? Because the link no longer has focus, a sub-menu link does. And, unlike with :HOVER, if you use :FOCUS on a block element and one of its children has focus, that parent block element, for whatever reason, is not considered to have focus.

This, I think, is a major flaw with current web browsers. If a child element has focus, so should its parent. Just like :HOVER. If this were how browsers worked then using :FOCUS would make CSS-based drop-down menus accessible for blind users with screen readers.

For now I have two options. Either display content in the drop-down menus outside of the menu or make sure each sub-menu option is accessible through the page its parent links to.