Looking for the lessons? Get started!
What “accessibility” is, and why your Web sites should be accessible
The entire Web Design Principles section can be accessed through the menu below.
Unfortunately, not everyone’s browser will support the spiffy JavaScript menu behind that innocent-looking button. If your browser won’t display the menu, just click on the button and you’ll be taken to a separate page with the entire menu displayed in clear, non-JavaScript HTML.
Accessible Web sites provide the maximum potential audience by allowing any Web user to access a site. — Web Design Group
Accessibility specialist Derek Featherstone writes:
At its core, web accessibility is about building Web sites, applications, and pages so that there are as few barriers to use as possible for anyone, regardless of ability and the devide used to access the information. Web accessibility goes beyond creating a more usable Web for persons with disabilities, too. Many of the techniques and principles designers apply to make Web content more accessible to people with disabilities also improve accessibility for those using slower connections who might have the images off as well as increase interoperability with handhelds.
And Web specialist Craig Grannell writes:
Designers (and clients paying for their time) aren’t the only ones to benefit from CSS. Visitors will, too, in terms of faster download times, but also with regard to accessibility. For instance, people with poor vision often use screen readers to surf the Web. If a site’s layout is composed of complex nested tables, it might visually make sense; however, the underlying structure may not be logical. View the source of a document and look at the order of the content. A screen reader reads from the top to the bottom of the code and doesn’t care what the page looks like in a visual web browser. Therefore, if the code compromises the logical order of the content (as complex tables often do), the site is compromised for all those using screen readers. Accessibility is now very important in the field of web design. Legislation is regularly passed to strongly encourage designers to make sites accessible for web users with disabilities. It’s likely that this trend will continue, encompassing just about everything except personal web pages. (However, even personal websites shouldn’t be inaccessible.)
Accessibility is often misunderstood as "designing for blind people." That is indeed one aspect of making Web sites accessible, but there is far more to the idea than just that. Freelance Web designer Mark Norman Francis writes:
The term "assistive technology" is used to describe any extra piece of computer equipment or hardware that helps a person interact with their computer more successfully. This normally brings to mind screen readers for people who cannot see, or voice input for people who cannot use a mouse or keyboard. But – what about glasses? People who need to correct their vision are also using an assistive technology. But most would not classify themselves as being disabled.
An awareness of the problems that people can face when trying to use the internet is important when developing good web pages. Don’t assume that your users will have a mouse; don’t assume that people can see the images you have used; don’t assume that everyone has Flash installed and provide alternative content for those without.
Usability and accessibility guru Jakob Nielsen has for years provided invaluable information and commentary about the subject. For more information, visit his site. However, much of the information in this site comes from the chapter by Featherstone, as cited above.
Types of Disabilities
Cribbing from Featherstone, we can look at four broad categories, or types, of disabilities that impact a person’s ability to interact with Web pages:
- Vision impairment
- Blind or low-vision users take advantage of assistive devices such as screen readers, Braille displays, screen magnifiers, and combinations.
- Mobility impairment
- Impaired or no use of hands; users employ modified mice and keyboards, switches, foot pedals, head wands, joysticks, and software solutions such as voice recognition, facial tracking, and keyboard macros.
- Auditory impairment
- While auditory impairments may seem secondary, Featherstone notes that users with little or no auditory cognition often process language very differently from sighted users. Audio and multimedia files require captioning, among other modifications.
- Cognitive impairment
- Memory impairments, reading difficulties, mathemathical processing, visual comprehension, problem solving, and attention impairments plague more users than most of us realize. These are the least understood, and usually least addressed, of the impairments being addressed. While there are few specific software and hardware solutions available, common wisdom tells designers to keep their pages, sites, and content as simple and clear as possible.
Assistive Technologies
There is a plethora of so-called “assistive technology” (sometimes called “adaptive technology”) devices on the market. Basically, these work to provide the same functionality as a keyboard and mouse. This means that you, the designer, need to provide methods for keyboard-based navigation and functionality in your site. A certain level of this is already implemented by most browsers, which allow users to use the Tab key to “tab” through the different links on a site, but there is more to it than that. These “assistive devices” can include alternative keyboards, “virtual keyboards” which appear on screen, voice-recognition software that allows the user to issue voice commands instead of mouse clicks or keyboard selections, head and mouth wands that press keyboards or touch screen monitors, adaptive switches that replace a mouse, eye-tracking devices that scan and track the movement of the eyeball to allow the user to manipulate computer input devices, and more.
This photo (a public domain image obtained from Wikimedia) is of a quadriplegic person using a head wand to activate a touch-screen monitor.
This photo (another public domain image obtained from Wikimedia) is of a Russian cosmonaut using an eye-tracking device to active devices on board the International Space Station. This technology has been adapted for use by disabled people.
Output devices such as screen readers, screen magnifiers, aural browsers, and Braille displays modify a computer’s output (visual and auditory) for use by disabled Web surfers.
This photo (yet another public domain image obtained from Wikimedia) is of a refreshable Braille display device. This allows blind or visually disabled users to read text displays in Braille.
Web Content Accessibility Guidelines
Most designers and accessibility experts look to the Web Content Accessibility Guidelines (WCAG) for help in determining how to craft their Web sites to meet the needs of disabled users. Although the WCAG 1.0 standards are a bit dated and do not always reflect the latest technologies, they are still quite useful.
The W3C provides a detailed set of guidelines for the “Priority 1” level of Web accessibility, the most critical “checkpoints” a design must meet. (Priority 2 and Priority 3 guidelines are less critically important, but still should be observed whenever possible.) Some of the Priority 1 guidelines are detailed below.
Note: The WCAG 2.0 guidelines have been available since 2008. Few of the critical elements have changed from the 1.0 WCAG, but the guidelines and implementations have been updated considerably.
Provide equivalent alternatives to auditory and visual content
Images need alt text. Audio content has captions provided. Video content has auditory or text descriptions.
Don’t rely on color alone.
Your nice, neat differentiated-by-color navigation links might not appear any different to a colorblind user; same with your form fields. Visual prompts such as underlines, asterisks, boldface, and other cues should be apparent.
Use markup and stylesheets and do so properly.
Yet another in the myriad reasons why you should use valid, standards-compliant code.
More about validating your site.
Clarify natural language use.
Identify the language of the document, and mark up your text’s abbreviations, acronyms, and foreign words and phrases.
More about formatting your text.
Create tables that transform gracefully.
Tables should be used only for tabular data, not for layout purposes.
Ensure that pages featuring new technologies transform gracefully.
Nowadays designers use the term “progressive enhancement” to indicate the use of new technologies (such as CSS3) that degrade gracefully in browsers that do not support them. A simple example is the use of the CSS3 border-radius property; in browsers that don’t support CSS3, the user just doesn’t get the spiffy rounded corners. No harm, no foul. More to the point, many users don’t allow stylesheets to function (you may laugh, but millions of mobile phone users, for example, don’t get CSS in their displays). Many others don’t have, or don’t allow, JavaScript to function. Does your site still function correctly with these technologies unavailable?
Ensure user control of time-sensitive changes.
If your site employs, say, a news ticker that automatically refreshes every so often, can users with reading comprehension limitations read the material before it flicks offscreen? Can they pause it to study it at their own pace? How about image “sliders” that display one image, then “slide” it offscreen to show another one?
Ensure direct accessibility of embedded user interfaces.
In plain English, this means that if you’re using interfaces built in Flash, Swish, or other non-standard technologies, are there alternatives to that interface for users who don’t, or can’t, use the fancy technologies?
Design for device independence.
Is the user entirely dependent on the mouse to move around your site, or is your site easily accessible by keyboard (or touch — think iPad and mobile devices)?
Provide clear navigation mechanisms.
How easy is it for users to figure out how to move around the various pages and elements of your site? Are you employing “mystery meat” navigation that makes it hard to use your site? Is there a sitemap? Do your link titles relate to the pages to which they point? Are you using text descriptions, or do your users need to figure out what an icon means? (California’s Consumer Corner used to use icons only in its left-side navigation, but as you can see, they’ve added text. And author Julie Garwood has a visually appealing interface, but the near-constant motion makes me queasy – God only knows how it would affect users with balance and perception problems – and the need to move around a metaphorical “desk” whose items “light up” when hovered over presents a plethora of accessibility problems.)
Ensure documents are clear and simple.
While no one is asking you to write with a 100-word vocabulary so even the most doltish of users can comprehend your site, you should write in clear, simple English (or your language of choice), using vocabulary appropriate to your audience. Use images to illustrate key or confusing points.
Section 508 Guidelines
In 1998, the US Congress passed the “Section 508 Amendment” to the Rehabilitation Act of 1973. This was envisioned to create a new level of accessibility for electronic and information technologies. You can read more about Section 508, as it’s routinely called, on Wikipedia. Legal standards in Canada, Australia, the UK, and many European countries fall generally in line with the Section 508 restrictions, which themselves are derived largely from the WCAG 1.0 Priority 1 guidelines. The WebAIM accessibility organization has a useful Section 508 checklist here.
Accesskeys and Tabindex
The use of accesskeys is one of the most controversial, and hotly disputed, techniques in making Web pages accessible. You can add accesskeys to your a:, or anchor, elements. It assigns a numeric “access key” (1-9, always a single digit). On a Windows PC, you’d press alt and the digit, and the cursor would immediately leap to the designated anchor element. On a Mac, the same effect is produced by pressing the ctrl key. At least this is how it works in theory. Some browsers take the user to the link, while others activate the link. Also, there is no definite standard of which links should be designated as what numbers, so the accesskey="1" designation on your site might take me to the Home link, while on my site it takes you to the Contact Me site. Or whatever. Worse, many of the alt+digit combinations are taken by other applications. Therefore, most designers just don’t use the accesskey.
The tabindex attribute is more successful. You can designate the attribute’s value as any number from 0 (actually excluding the element from the tabbing order) to 32767. Most designers use tabindex designations in steps of 10, allowing them to go back and insert new tabindex designations later without disrupting the order. Not all browsers enable tabbing to links, and others require some relatively tricky coding to enable the function, so mostly, tabindexing is left for use in forms, where the user can tab through the various form fields.
When used for too many other elements, you also run the risk of tabindex values hijacking the mouse cursor, meaning that instead of the Tab key moving the user from the first form field to the second, it might end up highlighting something totally different, elsewhere on the page. What’s logical to some people – in terms of tab order – may not be to others, so always ensure you test your websites thoroughly, responding to feedback.
