DAN STORM

skip to main content skip to secondary navigation

Accessibility Tutorial

Overview of Web Accessibility

Accessibility in its most general sense is characterized by the degree to which an entity or service is approachable, comprehensible, obtainable, usable, or interactive. Web Accessibility may be defined as the degree to which a user can access information, interact with that information, and complete common tasks such as making transactions, performing searches, or creating and updating account information.

Web Accessibility has surfaced as a priority in recent years because companies are being held liable for site inaccessibility. This is not surprising given that many web development efforts have given little, if any, thought to accessibility until recently. This state of affairs has given rise to a cottage industry of web design firms that advise clients in accessibility retrofitting, or who themselves perform the sometimes arduous task of retrofitting a non-compliant site.

Developers ought to take a strong interest in satisfying clients' legal and ethical obligations. What may not be apparent is the amount of lost revenue due to inaccessibility. Without an action plan to promote web accessibility development firms cannot justly position itself as expert in User Experience technology.

Accessibility More Broadly Defined: Design, Usability, and Coding for Assistive Technologies

Before we further outline web accessibility, we need to understand the concepts of web design and web usability.

Design

Popularly understood, web design has to do with the attractiveness and style of a website. For our clients, the function of style is to support branding. The most attractive websites are those that showcase web design. In this sense most would agree that some sites are infinitely more attractive than a site like Google. In fact, I would argue that most sites on the web are unattractive by this standard. On the other hand, attractive design may actually detract from a sight's usability and accessibility.

Again, design pertains to clarity. Is it clear what the link or image is intended to do? Is there sufficient white space around page elements so that the sighted user can distinguish page elements? Is critical information above or below the fold? Is content clear?

Usability

Usability pertains to site structure, layout of information, clarity of intent, and to what usability experts call "findability". A usable site is one in which a user can quickly find the information or product they are looking for. Content is clear, navigation is well organized, and design tends to be less cluttered.

Some sites rely on rollovers to determine what a certain icon is meant to do. This lack of immediate clarity must create a layer of confusion for many users. Surely it must be possible to present a beautiful design that conveys meaning without mediation. One can appreciate the finesse of such a site, but one may find that some of the design is for its own sake.

Google's site is more usable, and is indeed intended for general consumption. The purpose of that site is to search the web, and to that end the search bar is front and center. A script helps ensure that the user's cursor begins in the search field. A few additional common links are easily perused, and if they are not applicable, one soon finds a site map page. The Google site exudes usability.

Usability also has to do with information architecture. It is a general rule of usability that a user should not have to click more than three of four times to find what they want. On the extreme end of the spectrum a web page might have only a few links and some instructional text, and yet it might be very easy to find a link to drill down to the information you want. Perhaps you may have to click as many as four times, but the information on each page will lead to quick decisions as to which link should be followed.

The other end of the spectrum is a site like Amazon.com, which employs a "kitchen sink" approach. Each page is loaded with reviews, images, dozens (if not hundreds) of links, recent history, advertisements, and much more. It would seem that Amazon wants to minimize clicking and churn. The advantage to this approach is that once a user finds the right page, a simple content search on the page using a browser's find function should yield the desired information.

A recent search I made at Amazon yielded the desired results, in that the search results page was indeed useful. However, the size of the document I found, including CSS, JavaScript, and images was 353Kb, and had 325 links! Yet in some sense Amazon still succeeds at usability because they have an excellent search engine that includes an AJAX application to help supply your search terms. Drill-down and churn is minimal to find the right page, though finding what you want on a given page might be challenging for some.

Accessibility

Now let's consider Google and Amazon from an accessibility standpoint. Imagine two users. User A, who is blind, uses a screen reader. User B has a motor disability and uses only a keyboard to navigate. User A will spend very little time at Google's site listening with a screen reader before finding the right link or the search field because there are so few elements on the page. User B does not have to tab at all, if he is performing a search, since the cursor begins in the search bar if JavaScript is enabled. If he wants to follow one of the links, there are few of them to tab through.

Now our two users go to Amazon. User A wants to find the "Advertise with us" link, which is in the footer, but since it is link number 305 out of 325 it remains doubtful whether he will have the patience to sit through all of the links being read out by his screen reader, even considering that he set his screen reader to read only links. There is also no "skip to main content" link. User B can use his keyboard to search for the text "Advertise with us", so that he is better off. Otherwise, he would have to hit the tab key 305 times.

Amazon partly makes up for this by an excellent search engine, and from the fact that one can easily search within a page with a visual browser. But for a user who has to listen to the entire page to find something, or for a user, whether sighted or not, who has to tab through to the 200th link, this is not a good user experience.

But what then of accessibility proper? Is it solely the result of good design and good usability? No, it goes well beyond that. Good design and good usability can suffer from inaccessibility for any of the following reasons:

  • Images with text on them lacking alternative text.
  • Videos lacking captioning for the deaf.
  • Form labels not correctly associated with form elements, so that while they are in proximity to their respective form elements for the sighted user, the visually impaired user may not be able to make such an association, depending upon the nature of that disability.
  • No link to skip navigation so that the visually impaired user has to listen to the entire navigation scheme on every page.
  • Forms or links that require JavaScript, and therefore a user cannot complete a transaction or search.

If a site with poor design and/or poor usability is also not made accessible for assistive technologies, then the site may become entirely unusable.

The Problem of Determining Accessibility

It could be fairly asked why we need to understand accessibility when we already know that we are legally and ethically obligated to make our sites accessible. Is it not really the role of the web developer to know web accessibility? The answer is twofold. Web developers and QA testers themselves tend to know little about accessibility, which is why accessibility projects tend to be retrofitting efforts. Secondly, projects are generally not staffed appropriately to account for accessibility. Accessibility testing can be rigorous not only because specialized knowledge is required, but specialized tools are required as well. Understanding the target audience helps determine the level of effort, which then informs staffing.

Testing is further complicated by the difficulty of yielding definitive results. This can be illustrated with two examples. A website is coded in some flavor of HTML or XHTML. A validation tool can assess such a document and determine whether it passes or fails against the document type that is declared. Similarly, a CSS (cascading style sheet) document also can be validated against a certain standard and will either pass or fail. In both cases the results are definitive. But while there are tools to test a website's accessibility, and while sites can clearly fail at well-defined points, lack of failure does not constitute an accessible site. The knowledge that a site has passed only means that the developers have given the site a certain level of accessibility. In addition to using web accessibility tools, a site must be tested by persons of varying disabilities. The code that is generated, that is, the "view source", must also be inspected manually to ascertain that certain coding practices have been followed. Tools not only fail in their inability to ferret out all accessibility problems, they also cannot check for poor design and poor usability, which of themselves make for poor accessibility for all users, since as you may have gathered, accessibility applies to everyone. All automated accessibility validation tools suffer from insufficient robustness and hence yield false positives and false negatives.

The W3C acknowledges that there is currently no software that can adequately validate a web page for compliance. They make this recommendation:

"Validate accessibility with automatic tools and human review. Automated methods are generally rapid and convenient but cannot identify all accessibility issues. Human review can help ensure clarity of language and ease of navigation" (WCAG 1.0).

We have an obligation to understand the different types of accessibility issues so that we can better anticipate the types of technologies needed to address them. Without that understanding we risk providing low quality work to our clients, we risk exposing them to lawsuits, and we risk retrofitting our own work.

Accessibility is often thought to be the insertion of code in a webpage that makes the site work better with assistive technologies, such as adding alternative text to images, and so forth. This is but the outskirts of accessibility. As we have repeatedly, said, there are three factors that go into making a site accessible: design, usability, and special coding for assistive technologies. It is only the last item that is included in discussions of accessibility. But all three factors make a site accessible to people, whether or not they have disabilities.

The W3C has established three levels of accessibility. The correct level must be determined based upon resources and the target audience. A site need not meet the most rigorous accessibility standards for compliance, but if certain key components of the site fail to be accessible, then the owners of the site are more vulnerable to lawsuit.

Working Toward Accessibility: Web Standards

To address accessibility problems the World Wide Web Consortium (W3C) has published its Web Content Accessibility Guidelines (WCAG) 2.0, which is part of the Web Accessibility Initiative (WAI). These guidelines are quite useful, and are decidedly less complex than WCAG 1.0. The W3C had come under much criticism for not streamlining this documentation, and had perhaps very justly (and ironically) deserved the criticism of having written an inaccessible accessibility guide. WCAG 1.0 was too bogged down in particular technologies that change over time, preventing that documentation from remaining pertinent. WCAG 2.0 is more concerned with principles of accessibility, and in this regard is a major improvement over its predecessor.

Often the topic of accessibility is presented in the form of a mandate to provide a user experience to people with disabilities equal to that of the general population. The deaf community in particular is sometimes loath to apply the term disability to their condition since they possess an expressive and rich means of communicating. Without wading too deeply into this sensitive topic, it is generally acknowledged that a disability is a hindrance in some regard, even if there are creative and fulfilling ways to address those disabilities, and even if those means give some people an advantage over others, such as an ability to read lips over a distance. Aside from that caveat, web accessibility need not seek to provide an experience identical to all. A blind person will not likely enjoy a movie in the same way a sighted person enjoys a movie, even if the blind person has a headset with a separate soundtrack describing the action taking place.

The term "graceful degradation" is applied to user experience with regard to certain web technologies, such as Flash or JavaScript, or older browsers, such as Internet Explorer 6, color support, monitor size, and other factors, such that if a user chooses not to use a certain technology or upgrade his software, that experience will still be operable, though perhaps at a reduced level of service or experience. We could also use this term with regard to accessibility. A blind or deaf person, to cite just two examples, should be able to make use of a site, even if their experience is not directly comparable to that of a sighted and hearing person. The aim should be to provide a viable and workable web experience that gracefully degrades so that a user can complete a task, whether it is researching a topic or making a purchase. An inaccessible website prevents them from doing so. If a site has a Flash animation, a blind person will not enjoy it to the same degree that a sighted user will. However, an alternative to the Flash can be provided whether in the form of a description of the animation, or in the case of Flash navigation a navigation scheme that does not use Flash. In the end, the experience of a disabled person might not be equal to that of the general populace, but accessibility mandates that the disabled user have an end-to-end experience, that is, one without barriers.

The WCAG 2.0 guidelines articulate four principals of web accessibility, and several guidelines corresponding to those principals. Principle one is "Information and user interface components must be presentable to users in ways they can perceive."

Text Alternatives Need to be Provided for Any "non-text content"

Textual equivalents need to be provided for images and Flash animations. These equivalents can be read or spoken by a speech synthesizer, and can be converted to other formats such as Braille, speech, symbols, or simpler language. Non-text content should also be re-sizable. Any user turning off images—perhaps because they have a dial-up connection—should see alternative text in their visual browser. A compliant browser like Firefox displays the alt text in such a way that the user does not even know that an image was meant to be displayed.

Provide Alternatives for Time-based Media

Alternatives need to be provided for audio, animation, or video including captions, descriptions, and sign language.

Content Must be Adaptable

In contrast to supplying text alternatives, WCAG recommends that content be manipulable so that it can be restructured or resequenced so that comprehension does not solely on color, size, or order of presented material.

Content Must Be Distinguishable

Web authors must not rely solely on color to communicate since some users are color blind. Moreover, the color contrast between foreground and background must be sufficiently different so as to be distinguishable.

To ensure text readability, text must be resizable, leading must be sufficient to enable the eye to distinguish lines of text, and columns of text must not exceed a certain width.

Audio must have a mechanism by which it can be paused.

Content Must Be Operable

Principle two is "User interface components and navigation must be operable."

Keyboard Functionality

All functionality must be available from a keyboard such that a user can tab easily from one page to the next to within a page.

Time to Perform Operations

Users must be provided sufficient time to read and use content, including allowing a user to extend the session timeout and not lose information if a timeout occurs. Users must be allowed to pause animations, pause scrolling, pause audio and video playback, and override auto-refreshing of pages.

Obviate Seizure Risk

Because of seizure risk, flashing should not occur more than three times per second.

Navigability

Content must be easy to find, and users should be able to determine easily where they are in the site and on a page.

Content Must Be Understandable

Principle three is "Information and the operation of user interface must be understandable."

Make Text Content Readable and Understandable

The markup must be encoded with the default language, and each portion of content that appears in a different language needs to be so indicated. Unusual words, such as jargon, abbreviations, acronyms, and slang should be so marked to facilitate identification and understanding.

Web Pages Must Appear and Operate in Predictable Ways

Content should not change on focus, such as putting the cursor in a text field or clicking on a radio button. The order of navigation links should remain the same. All content change should be user-initiated, or if not, there should be a mechanism to turn off automatic content updates.

Input Assistance: Help Users Avoid and Correct Mistakes

User input needs to be checked before submission, with errors flagged and the user given an opportunity to correct the errors. A form submission should be reversible for a reasonable period of time in case it was submitted accidentally.

Content Must Be Robust

Principle four is "Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies."

Maximize Compatibility with Current and Future User Agents, Including Assistive Technologies

Simply put, the site should be marked up in a way that it is usable by a host of devices including browsers, screen readers, phones, PDAs, Braille devices, etc.

Levels of Conformance

The W3C highlights three levels of compliance: A, AA, and AAA, with each level being stricter than the preceding. They state that all websites must conform to level A, should conform to AA, and may conform to AAA. They do, however, admit that level AAA is currently impossible to attain for some types of content.