Webforumz Newsletter - February 2008
Articles
Accessibility Neanderthals: Three Ways You Might be Hurting Instead of Helping
Accessibility, like other web theories and technologies, is an evolving field. And unfortunately, there are still some weak accessibility techniques that have made it through evolution's natural selection process and are still hanging around, refusing to become extinct and make way for newer, stronger techniques.
It's all too common to add a feature
to your web site that's intended to increase accessibility but simply doesn't. Not only do some accessibility techniques fail to help, but some can actually decrease the degree of accessibility on your site. We'll take a look at three well-intentioned but ineffective accessibility techniques that you should probably retire from your sites.
Text-only Pages
The fall-back accessibility technique specified by both Section 508 and WCAG guidelines is to create a text-only version of each page of a site. The idea is that instead of adding alternative text, heading markup, and making other accessibility improvements to a web page, it would be easier to just strip out everything but the text and present that to users of assistive technologies (such as screen readers; abbreviated AT) as the easiest way for them to access the content. Here's the big problem: no one uses text-only pages.
When text-only pages first became popular in the 1990s, many AT users did access text-only pages. Unfortunately, the content they found was usually out of date and did not match the content on the main, graphical version of the page. Although text-only pages can be generated dynamically, it was more common in the days before content management systems for text-only pages to be created manually. While the web designer might remember to create two versions of every page when initially building the site, it was very unlikely that every text change that came up during the long maintenance phase of the site would also be incorporated into the text-only version.
Without up to date content, text-only pages are pretty pointless, and AT users quickly grew to mistrust them and not bother with them. Even if you are able to dynamically generate text-only pages that will always be perfectly up to date, they'll probably be seen and used by no one.
Another problem with text-only pages is that they don't address the needs of all people with disabilities, but instead focus only on blind screen reader users. People with other types of disabilities, such as learning disabilities, may find text-only web pages harder to use than graphical ones. Remember that text is not the only content on most web pages. Images, audio, and video can be content as well, and by stripping those out you may be removing important information for an entire group of users. Instead of removing this content, use techniques such as alt attributes to improve the accessibility of images and other non-text content.
Finally, remember that the user has to go through the graphical page first to get to the text-only page. If you use the text-only page as an excuse to not take care of the real accessibility issues on your graphical page, it may be very difficult to find your way to the text-only page link in the first place.
Don't fool yourself; if you've created text-only pages to take care of accessibility, you really haven't even begun. Stop updating two sets of pages and spend the time you'll save making the often small but powerful changes to your graphical pages that will really help the greatest number of users.
Tab index
Tab index is the (X) HTML attributes that controls the order in which focus is applied to links and form elements when the user presses the tab key. The idea behind tab index is that occasionally, especially in very complicated table layouts, the natural order of links and forms elements in the (X)HTML source is illogical and confusing.
Tab index aims to fix this problem by overriding the natural tab order of links and form elements to a more "logical" one set by the web designer. Those that have tab index set receive focus in ascending order of the numeric tab index value, and then any remaining links or form elements will receive focus in their natural order from the top of the page down. This is good in theory, but there are a couple of problems with tab index that make it a less than ideal tool for the job.
First, tab index can actually cause more confusion when combined with other methods of navigation available to AT users. For instance, many screen reader users skim over a web page by jumping from heading to heading using keyboard shortcuts. A user may locate the heading they want, such as "World News" on a news site, and then use the tab key to move to the first link under that heading, such as the first news story under that heading. However, if the site has tab index set on links or form elements lower in the (X)HTML source, the tab key will not take the user to that first link under the heading, but rather to whatever comes later in the code with the tab index. The user will be lost, confused, and quite possibly angry.
Consider also that many keyboard users are sighted but simply unable to use a mouse. As they tab through the page, they can see the next link or form element on the page and expect to be taken there next. Instead, your tab index order could take them to a completely different spot on the page. They'll have no idea how many times they'll have to keep pressing tab to get back to the link or form element they are trying to target. Also, if they press shift+tab to move back to the last link or form element, they'll be taken to the last one in the (X)HTML source, not the last one they were at before tab index moved them elsewhere. Again, tab index is setting you up for some confused and unhappy users.
Another problem is that tab index takes care of the symptoms of illogical source order without actually fixing the problem. If the order of the links or form fields in the (X) HTML source is illogical, fix the order of the source. Modern CSS layout techniques make it much easier to manipulate the source order to meet the needs of users of screen reader text browsers, mobile devices, and others who access content in a linearized way. Even if you're still using a table-based layout, there are usually changes that can be made to simplify the table structure into a more logical flow. This usually ends up benefiting not only people with disabilities, but also you the web designer, as simpler tables with more logical content structure are easier to maintain. In both cases, you can supplement the improved source order with additional accessibility techniques, such as skip navigation links, to improve in-page navigation in a much less confusing way.
Access keys
Access keys are another technique designed to improve navigation around a page that usually ends up causing more problems than they're worth. The access key (X) HTML attribute can be placed on links and form elements to assign a letter or number as a keyboard shortcut to that element. This allows AT users to jump straight to the link or form field they want, usually by holding down alt and the key set as the access key (variations occur between browsers), from anywhere else on the page.
The problem is that the keyboard shortcuts you assign are almost guaranteed to conflict with a keyboard shortcut already used by other software. This is especially bad for AT users, such as blind screen reader users, as many rely heavily on numerous keyboard shortcuts present in AT because they cannot use a mouse. When there's a conflict, the browser keyboard shortcut loses and the access key shortcut wins, sending the AT user to a different spot on the page or even an entirely new web site without the user ever intending to trigger such a thing.
Even if access keys worked without overriding other shortcuts, the shortcuts provided by access keys are not intuitive. They're set by the web designer at random, so the user will have to memorize shortcuts for each site they visit. That's assuming they even know the shortcuts exist: many AT programs do not support access keys or make their presence known to the user, so it once again becomes an issue of your accessibility effort being wasted.
The UK government developed a recommendation for access keys that eases these problems a little bit. They proposed almost entirely numbers as the shortcut characters, as well as standardized which number would act as a shortcut for which common web site feature, such as search and FAQ. Numbers are almost the only characters that won't conflict with other keyboard shortcuts, so they're fairly safe to use.
However, it's still possible for a conflict to arise if the user wants to type a special character, such as an accented letter or em dash. The user may have to hold down the alt key and then a numeral to begin typing the special character code, and this would then trigger one of the numeric access key shortcuts and move his or her cursor to an entirely different spot on the page. This would probably not affect many screen reader users, as their software will be in Forms Mode while typing the characters and will ignore other page elements, but it would affect all non-screen reader users who want to use keyboard shortcuts. Once again, an accessibility feature has actually made the page harder to use for those it was designed to help.
There are some cases where access keys are very helpful (again, best restricted to numbers). People with learning disabilities often find them very useful, as do people using small handheld devices. If you're developing an intranet or some other site with a controlled user or device base, you may consider using them if testing reveals your users will benefit. However, it's almost always best to avoid using them entirely and instead use a different accessibility or usability technique to accommodate the navigation needs of these other groups of users.
Keeping Up with Evolution
All of these techniques became recommendations because there were real shortcomings in how people with disabilities were able to use web pages. Although the techniques themselves proved not to be very helpful in solving these problems, the problems are still very real and deserve your attention using others.
Before implementing any accessibility technique, make sure you understand the reasoning behind it, who it's supposed to help and how. If you're not sure whether the technique really will help as advertised, try to find some people with disabilities to ask about it, or test a web page for you. And of course, keep up to date with new recommendations and software, as these techniques may become viable again in the future if modified or as AT and browser implementations change.