You are here:
Do's and Don'ts For Building Accessible Websites
Editor's Note: Bruce Etheridge is a Web and Documentation Specialist for the University of Toronto's Adaptive Technology Resource Centre (ATRC). He is also a former award-winning web and magazine editor and has been involved with a variety of organizations dedicated to assisting persons with disability since 1987.
With anti-discrimination laws being developed to safeguard the rights of persons with disabilities in virtually every country in the western world, web accessibility is fast becoming a requirement rather than simply an option for web developers.
Section 508 of the United States (U.S.) Rehabilitation Act, for example, ensures that the websites of all vendors conducting business with the U.S. federal government meet clearly defined accessibility guidelines.
In Australia in 2000 a complaint was filed against the Sydney Organizing Committee for the Olympic Games (SOCOG) on the grounds its website was inaccessible to blind people. Australia's Human Rights and Equal Opportunity Commission agreed and, when SOCOG failed to rectify these accessibility issues, a fine of $20,000 (AU) was levied against the committee.
In Canada, the federal government's Common Look and Feel (CLF) guidelines and legislation, such as the Accessibility for Ontarians with Disabilities Act (AODA), are precursors to more stringent regulations that will inevitably follow as this country's population ages and disability issues become a priority. (At present, web developers are not compelled to make sites accessible, and the AODA as it now stands does not specifically address web accessibility issues.)
Aside from the standard "include ALT text with images", what can developers do to make their websites more accessible?
- Build accessibility into your web design from the outset. Planning is the key when it comes to creating an accessible website and this critical first step is one web developers often overlook.
An additional reason to plan accessibility into your initial design is cost. Eventually, legislation in Canada will require websites to conform to accessibility standards and it is far costlier to retrofit a site than to factor in accessibility from the beginning.
To make the SOCOG site accessible, for example, experts estimated the cost at more than $10,000 (AU), whereas if accessibility had been a consideration from the outset, it would've added only two percent to the website's overall budget.
Use text wherever possible. Persons who rely on screen readers, braille displays, and those with hearing impairments will always be able to access web content that is presented as text. That is not always the case when images are used in place of text or when multimedia/audio content is not reproduced textually.
Provide "meaningful" text equivalents for images, applets, scripts, and objects that are used in place of text. The purpose of "alt" text is to provide a textual equivalent when an element cannot be displayed by a browser or viewed by a user.
Most web developers recognize the importance of including "alt" text within their web pages, but many fail to provide meaningful text equivalents. Alt text should describe the purpose of the element within the context of the web page.
Before writing "alt" text, first consider what information the element is meant to convey.
If an element such as an image includes important text, then that text must also appear in the "alt" attribute.
Do not use an element's filename, file size, or file extension as "alt" text.
Do not use null (i.e. alt="") or empty (i.e. alt=" ") "alt" attribute values for important content. (Null or empty "alt"
text is acceptable for decorative elements.)
"Alt" text should not exceed 150 (English) characters. (For elements that require a detailed explanation, use the "longdesc" attribute and d-link.)
Do not use placeholder text (i.e. alt="image goes here") as "alt" text.
"Alt" text for anchors should specify the destination of the link (i.e. alt="U of T bookstore".
Avoid creating links that open a new browser window, launch pop-ups, or shift the focus of a user's system to a new frame. When a link forces a new window to open, it drastically changes the focus of a user's interface. This can be extremely disorienting for any user, but particularly for those who are blind.
Opening a new window also disables a browser's "Back" button, which can be frustrating even for sighted users (new windows do not inherit the history of the originating browser window).
Although some screen readers announce when a new browser window has been opened and others play a distinctive sound, these auditory signals can be missed during the reading of a web page. Blind users obviously cannot look at the taskbar to determine how many windows are open and must direct the screen reader to list all open windows if focus is lost in the current browser.
Low vision users who set their browser windows to automatically open at full screen size to view content more easily will also have difficulty determining when a new window has been opened. Each new window will appear overtop of existing Windows, concealing them from view. Windows XP users will have an especially difficult time because multiple windows of the same application are automatically grouped together, making it virtually impossible for someone with low vision to determine that a new window has even been opened.
- Enable users to bypass repetitive content (such as navigational arrays that appear at the top of each page) by imbedding a skip over link within each web document. Typically, the first item users encounter in an HTML page is a navigation bar. For screen reader users, long lists of navigational links can be a source of frustration and a barrier to accessing content.
While sighted persons can skip over repetitive content visually, a blind person must listen to the screen reader repeat each link every time a web page is accessed. A skip over link enables users to bypass repetitive content and get to the main body of the web document quickly and easily.
There are several methods for using HTML markup to bypassing groups of links automatically. One method is to use the MAP element to create a grouping; another is to create a transparent link visible only to screen readers.
- Ensure link text is meaningful. Link text must clearly identify the target or destination page. Blind and low vision users often direct their screen readers to scan web pages for hyperlinks. This creates a list of links that are presented to the user out of context. Links that have labels such as "click here" or "select link" are meaningless to these users.
In addition, such text focuses on the mechanics of activating a link rather than identifying the destination page's content, implying that the link can only be activated using a standard pointing device such as a mouse. Individuals who are mobility impaired often use alternative input devices such as switches, a head wand, or track ball to activate hyperlinks.
When writing link text, be sure it:
Describes the destination page;
Remains meaningful when read out of context;
Is succinct (i.e. four words or less);
Does not include verbs referring to link activation;
Does not contain URL pathnames.
Provide text transcripts for audio, visual and multimedia content. Text transcripts for audio content require web developers to reproduce spoken words, song lyrics etc. verbatim, and sound effects should also be described. Visual content requires a full description of scenes, actions, body language, images and illustrations/graphics. Transcripts provide persons who are blind, deaf, or use browsers that cannot play movies, animation or slide shows a textual equivalent of the information in an accessible format.
Design for device independence by including keyboard equivalents for all actions on your website. This ensures that blind users and those with a mobility impairment who cannot use a mouse (or other traditional pointing device) have full access and are able to interact with your website.
If, for example, a form control such as a "Submit" button can only be activated via a mouse, an individual who is blind using voice input software wouldn't be able to submit their information. A web page designed for keyboard access will, typically, be accessible to other input devices.
Developers can add keyboard accessibility to their site through the "accesskey" and "tabindex" attributes.
- If colour is used to convey information, make sure that the information is also available through alternate means (i.e. through the context in which the information is presented or its markup properties). A simple test to determine whether a web page's content is colour-dependent is to disable colours in your browser or view the page using a monochromatic monitor.
A common error web developers make is to rely on colour to identify text links when the text-decoration attribute is set to none (i.e. the underline is removed from all links). Many low-vision and colour-blind users will not be able to distinguish a link from body text if colour is the only technique used to indicate a hyperlink.
Another common problem related to colour is found in web documents that ask users to make a selection based on colour (i.e. "Choose one item from the list in red, one from the list in yellow, and one from the list in green"). Obviously, individuals who cannot view colours, either due to a visual impairment or because they view web pages monochromatically, will not be able to distinguish between these lists.
- Present text in a linear format. Using tables and columns to position text on a web page can cause significant barriers to persons using screen readers and text-to-speech software.
Typically, text-to-speech software reads across web pages rather than down table columns. As a result, when text is presented in a non-linear format, text-to-speech technologies read the first line in column one, the first line in column two and so on until the end of the row. This process is repeated at line two of the first column. Obviously, having a web document read in this fashion renders the content unintelligible.