|
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.
About the Author
Zoe Gillenwater is a web designer
and web standards advocate and author. She currently works as the
Design Services Manager at the UNC Highway Safety Research Center
[link: http://www.hsrc.unc.edu]. She is also the author of lynda.com's video course Web Accessibility Principles and a member of the Adobe Task Force for WaSP.
|
iEntry 10th Anniversary
Announcements
Contact
