Making Your Organization's Website More Accessible and Usable

Making Your Organization's Website More Accessible and Usable

Website accessibility is less complex than many people believe. It primarily involves adherence to a small number of basic rules for including certain codes or content in ways that can be interpreted effectively by people who are not using the standard monitor, keyboard, or mouse to access and interact with websites.

Guidelines and Standards

Most national and international accessibility guidelines are based on at least one of two sources:

  • The Web Content Accessibility Guidelines (WCAG), developed by the World Wide Web Consortium (W3C). WCAG 1.0 was published in 1999; WCAG 2.0, which is a major revision, was published in 2008. Among other changes, WCAG 2.0 strives to remain relevant as new Internet technologies are developed. WCAG is based on best practices, and is not formally affiliated with any legislation. WCAG has three levels of compliance: A (minimal compliance), AA (enhanced compliance), and AAA (advanced compliance). This document covers Level A and Level AA compliance.
  • Section 508 Standards, which were published in 2000 and are enforceable for Federal agencies under the Rehabilitation Act of 1973. Subpart B, 1194.22 covers Internet and intranet pages. Section 508 is slated for revision in the near future; when the revised standards are published, they will dovetail far more closely with WCAG 2.0. Title III of the Americans with Disabilities Act, which addresses accessibility of places of public accommodation, has recently been amended to cover website accessibility. When Title III standards are published, they will likely be based on WCAG 2.0 and/or Section 508.

What Website Accessibility Means

Website guidelines and standards primarily address two issues:

  • Coding. Many people with disabilities use assistive technologies to access the Internet. Assistive technologies provide an alternative to the monitor (e.g., programs that read information aloud) or to the keyboard and/or mouse (e.g., speech recognition software). These programs are often dependent on the presence of certain HTML tags, attributes, or other pieces of coding to work properly.
  • Interface. The “look and feel” of websites needs to be designed so that they are accessible to people with disabilities, whether or not they use assistive technologies. These guidelines and standards overlap significantly with mainstream usability guidelines. WCAG Level A guidelines primarily cover coding issues; Level AA guidelines cover both coding and interface.

This article discusses Section 508, Level A, and Level AA guidelines, and provides suggestions on how to comply with each of these.


Guidelines Common to Section 508 and WCAG 2.0

These guidelines are currently included in both Section 508 and Level A or Level AA of WCAG 2.0.

1. Graphics—Provide a text equivalent for every graphic element

Section 508: 1194.22 (a), (e), (f)
WCAG 2.0: 1.1.1

Text equivalents, which are an alternative means of understanding graphics, are provided by adding an ALT attribute to the IMG tag. Keep in mind that these will be perceived not only by blind people, but also by anyone who has turned off graphics loading to speed up page download time and by some individuals who use technologies other than a computer to access the Internet.

There are four primary types of graphic elements, each of which require a different strategy for assigning text equivalents:

•    Meaningless. This includes divider lines, bullets, invisible spacer graphics, etc. These should always take a null equivalent (ALT=””).
•    Bitmapped. These are graphics that contain bitmapped text. These should take an equivalent that matches the text. (See also topic 21, “Bitmapped Text,” below.)
•    Illustrative. This includes photos and other images that add to the visual appeal of the page. Some blind people prefer that these take a null equivalent; others would like to hear a short description (e.g., ALT=”Photo of Mary handing a flower to John”). Consider providing descriptions if there are only a few illustrative images on a page; otherwise, provide null equivalents.
•    Meaningful. This always includes charts, graphs, and other graphics that convey information; in some contexts, it may include illustrative graphics (e.g., for a fashion site, descriptions of all clothing worn by models would be critical). It also includes any graphics that serve as links. If you can describe the element using 150 characters or fewer, do so in the ALT attribute, for example, ALT=”Model wearing short sleeveless yellow dress with wide red belt, white mesh hat with a wide, floppy brim, and white sandals with stiletto heels.” If a longer description is needed, provide a brief text equivalent such as ALT=”Graph of November sales figures.” Then, underneath the graphic, either provide a complete text description or provide a meaningful link (e.g., “Click here for a text description of sales figures”) that goes to the description on a separate page.

Section 508 also talks about server-side and client-side image maps (hyperlinked coordinates within an image). Server-side image maps are now obsolete, and text equivalents for IMG tags within a client-side image map should be handled as meaningful graphics.

A special case covered by WCAG 2.0 is CAPTCHA elements, which test to ensure that forms are submitted by humans rather than spambots. There has not yet been a CAPTCHA devised that is usable by all people with disabilities, and most have been shown to not provide satisfactory protection. Anti-spam measures that do not require input from users are therefore preferable.

2.  Multimedia—Provide equivalent alternatives for audio and video.

Section 508: 1194.22 (b)
WCAG 2.0: 1.2.1, 1.2.2, 1.2.3

People who are Deaf or hard of hearing will not be able to access information presented only in audio form, blind people will not be able to access information presented only visually, and people with low bandwidth may not be able to access either. To meet WCAG Level A guidelines, provide a transcript of dialogue, significant sound, and significant visual action, e.g.:

RICK: Now, now.

(He lifts Ilsa’s chin. Her eyes are teary. The tune of “As Time Goes By” is playing.)

RICK: Here’s looking at you, kid.

(They continue to look at each other, and she smiles slightly. Then Ilsa and Victor turn and begin to walk towards the plane.)

The same model should be used for audio-only content, such as podcasts, and video-only content.

To meet Level AA guidelines for multimedia files, provide captioning and audio description within the video itself. Various initiatives are being developed to facilitate this.

3. Color—No information should be conveyed solely by color.

Section 508: 1194.22 (c)
WCAG 2.0: 1.4.1, 1.3.3

Blind people, color-blind people, and others may find it difficult or impossible to interpret information such as “The green circle means yes and the red circle means no,” and “Note the percentage of users illustrated by the blue bar in the chart.” Whenever information is conveyed by differences in color, it should be redundantly conveyed via other means, such as shape (e.g., “The green circle means yes and the red triangle means no”) or text (e.g., provide labels for the bars in chart, or provide a text equivalent as described under “Graphics,” above).

WCAG 2.0 Level A compliance further requires that items not be identified solely by their sensory properties (e.g., shape or sound) or by their position on a page (e.g., “the button on the left”).

4. Style Sheets—If the default style sheet is inactive, or an alternative style sheet is used, the page should still be usable.

Section 508: 1194.22 (d)
WCAG 2.0: 1.3.1, 1.3.2, 1.4.4, 2.1.1, 2.4.3

While style sheets can be tremendously useful for providing accessibility, pages still need to be usable if the default style sheet is turned off or supplanted. There is an easy way to test for compliance with this guideline: in Firefox, go to the View menu and select Page StyleNo Style. Then review the page. Is the page still legible? Are related elements still presented together? If not, you will need to examine page coding to see how to structure this information so that it is not dependent on the style sheet.

For WCAG conformance, some additional considerations need to be addressed whether or not the default style sheet is active:

•    Blind and other non-mouse users will frequently interact a page by repeatedly pressing the TAB key to reach interactive elements. Try this with your page; if you do this, are you navigating in a logical order, particularly if this order is important for the page function? If not, you may need to apply markup and CSS elements to be in conformance with Level A.
•    Can text be resized and still be legible? The Zoom feature in most browsers now handles this automatically, but the Text Size option in Internet Explorer may be preferred by some users since it controls the font size for printing as well as for onscreen display. In style sheets, this is controlled by defining font-size using relative font sizes (expressed in em or percentage units, or as named sizes such as “larger”) rather than fixed sizes (pt or px). If the style sheet is turned off, the page will usually respond appropriately to Text Size settings.

5. Data Tables—Data tables should have appropriate code markup for row and column headers. Table structures used only for layout should not have this markup.

Section 508: 1194.22 (g), (h)
WCAG 2.0: 1.3.1

Below is an example of a data table:

Widget Sales:
    Thingamabobs    Doohickeys    Whatzits
January    540    270    333
February    580    224    882
March    998    334    345

To understand the contents of a cell containing data in context, blind users need to hear the associated column and row header. This is done by marking up headers using a <th> tag instead of a <td> tag, and providing a SCOPE attribute to indicate whether it is a row or column header. For the table above, the following markup would be included:

<th scope=”col”>Whatzits</th>
<th scope=”row”>January</th>

Some tables have multiple header levels, such as the following:

    Thingamabobs    Doohickeys    Whatzits
    Things    Bobs    Dooz    Hickeys    Whas    Tzits
January    540    24    270    1453    333    154
February    580    545    224    45    882    341
March    998    413    334    254    345    45

These are difficult to make accessible and should be broken into multiple tables or otherwise re-engineered to have single header levels.

6. Frames—Frames and iframes should have descriptive titles.

Section 508: 1194.22 (i)
WCAG 2.0: 2.4.1

Frames have been largely replaced by other, more accessible layout techniques, such as <div> tags. However, if <frame> tags are used, they should have a title that provides a brief description of each frame’s function within the page for the benefit of blind users, e.g.:

<frame src=”linklist.html” title=”List of page links”…>

7. Flicker—Any elements that flicker need to be outside a hazardous frequency range.

Section 508: 1194.22 (j)
WCAG 2.0: 2.3.1

Objects that flicker within the range of 2 Hz to 55 Hz can cause seizures in people with photosensitive epilepsy, especially if the object takes up a significant part of the visual range or if the color red is flashing. It’s best to avoid use of such objects. If this is not possible, either make sure they flash fewer than three times per second, or link to them on a separate page with a warning to photosensitive individuals.

8. Alternative Pages—If the page cannot be made accessible, provide an alternative page.

Section 508: 1194.22 (k)
WCAG 2.0: 1.3.1

Although at present almost any element can be made compatible with assistive technologies, there are still some exceptions, particularly for items scripted in Flash. However, it is better to provide an alternative through the same page rather than through an alternative page, since it can be onerous to maintain two separate versions of the same page.

9. Scripts, Plug-Ins, and Applets—Ensure that these are compatible with assistive technology and with keyboard-only use.

Section 508: 1194.22 (l), (m)
WCAG 2.0: 4.1.2, 2.1.1, 2.1.2

WCAG 2.0 has tried to not only address current Internet scripting languages, such as Javascript and Flash, but also to anticipate future capabilities; the language is therefore broad. The best strategy is to look at the website for the specific language and see what information it provides on either creating elements that will work with assistive technology or on providing accessible alternatives.

An important part of meeting these criteria involves making sure that any functions can be controlled via keyboard commands, without requiring mouse use. This is particularly critical for blind individuals, but it also many sighted users with physical or cognitive disabilities. If any element in the form, such as a “Submit” button, is created using Javascript, you will need to make sure that the event handlers (the code that specifies how elements respond to being activated) are not dependent on use of a specific device, such as a mouse. Device-dependent event handlers are onMouseOver, onMouseOut, and onDblClick; they should be replaced or used redundantly with device-independent event handlers including onFocus, onBlur, onSelect, onChange, and onClick.

If you are using scripts, plug-ins, or applets from third party sources, be aware that these may not be accessible. Discuss this with the provider, or look for an alternative.

10. Forms—Make sure the purpose of each form field can be identified, and the form field can be filled in.

Section 508: 1194.22 (n)
WCAG 2.0: 1.3.1, 2.1.1, 2.1.2, 3.2.1, 3.2.2, 3.3.1, 3.3.2

Most form fields—text fields, radio buttons, checkboxes, etc.—are still created using HTML. The fields themselves are accessible, but labels may be placed so that it is confusing for blind individuals to know the purpose of each field. This can be addressed by explicitly associating labels and fields using a FOR attribute in the <label> tag and an ID attribute in the <input> tag. The value of these two attributes should be identical.

Examples of appropriate syntax for various types of form fields are:

Text fields:
<label for="movie">Movie title:</label>
<input id="movie" type="text" name="textfield" />

<legend>Select one or more rock groups:</legend>
<input id="rst" type="checkbox" name="group" value="rst" />
<label for="rst">Rolling Stones</label><br />
<input id="bea" type="checkbox" name="group" value="bea" />
<label for="bea">Beatles</label><br />
<input id="byr" type="checkbox" name="group" value="byr" />
<label for="byr">Byrds</label><br />

Radio buttons:
<legend>Choose one dancer:</legend>
<input id="bary" type="radio" name="dancer" value="bary" />
<label for="bary">Baryshnikov</label><br />
<input id="nij" type="radio" name="dancer" value="nij" />
<label for="nij">Nijinsky</label><br />
<input id="nur" type="radio" name="dancer" value="nur" />
<label for="nur">Nureyev</label>

Pull-down lists:
<legend>Choose a painter:</legend>
<input id="pol" type="radio" name="painter" value="pol" />
<label for="pol">Jackson Pollock</label><br />
<input id="war" type="radio" name="painter" value="war" />
<label for="war">Andy Warhol</label><br />
<input id="van" type="radio" name="painter" value="van" />
<label for="van">Vincent Van Gogh</label>

If any element in the form, such as a “Submit” button, is created using Javascript, you will need to make sure that the event handlers are device-independent; see “Scripts, Plug-Ins, and Applets,” above.

11. Skip Navigation—A method should be provided to allow users to bypass lists of links that appear on every page within a site.

Section 508: 1194.22 (o)
WCAG 2.0: 2.4.1

There is no blind equivalent for a glance; when blind users approach a new page for the first time, they generally review it in a linear fashion. If they need to hear lists of more than four repetitive links each time they get to a new page, this can get tremendously time consuming. To avoid this, “skip navigation” strategies can be used to bypass these links. There are multiple ways to do this; because there are some sighted users who can benefit from use of skip navigation, we recommend using a “Skip to Main Content” link at the beginning of the page that is either visible or becomes visible when it receives focus. This link has a corresponding anchor at the beginning of the content unique to that page. Other “Skip to…” links may be used as deemed appropriate, based on the page structure.

12. Timed Responses—If a site or page function is time-dependent, users should be able to extend the time needed or pause the function.

Section 508: 1194.22 (p)
WCAG 2.0: 2.2.1, 2.2.2

Assistive technology users and other individuals with (and without) disabilities may not be able to respond fast enough if a user login times out, or if text scrolls by quickly. Depending on the function, an appropriate strategy should be determined to give the user additional time to read and, if necessary, respond to the function.

Level A Compliance

The following guidelines are not currently part of Section 508, but are required for WCAG 2.0 Level A compliance.

13. Page Titles—Provide concise, unique, and descriptive titles for each page.

WCAG 2.0: 2.4.2

Usually, the first thing blind individuals hear when they go to a new page is the title, and they may refer back to it to confirm the page they’re on. The <title> tag in the Head section of a web page should be used to provide a title that briefly conveys the meaning of the page and the website. It is a good idea to start with unique information and follow this with a divider and the brief name of the site, e.g., <title>Financial Aid | Lawrence University</title>

14. Language—Indicate the primary language of the page.

WCAG 2.0: 3.1.1, 3.1.2

Speech output programs used by blind individuals depend on knowing the human language used in the page, so that they can use appropriate pronunciation rules. The language is conveyed as a LANG attribute in the <html> tag; to specify American English for an HTML document, the tag would read:

<html lang="en-US">

Level AA compliance indicates that if the language changes within the document, use a LANG attribute as part of another tag, such as <span>, e.g.:

Marie Antoinette is credited with saying, <span lang=”fr”>”Qu’ils mangent de la brioche,” <span lang=”en”>usually mistranslated as “Let them eat cake.”

15. Code—Validate all code to ensure it meets the appropriate standards.

WCAG 2.0: 4.1.1

Several validators are available to make sure that all page code is compliant with the standards listed in the DOCTYPE statement at the beginning of each page. Because assistive technologies may be dependent on valid code, pages should be checked for validity.

16. Automatic sounds—If the page plays a sound for more than three seconds, the user should be able to change the sound’s volume or turn it off.

WCAG 2.0: 1.4.2

Some sites automatically play audio, usually to capture visitors’ attention rather than as an essential feature. Hearing audio from both the site and a screen reader will cause significant problems for blind users. If automatic playing of audio cannot be avoided, there should at least be a way for users to either turn it off or turn down the volume with a control that is independent of the operating system (since adjusting system controls would also adjust the volume of the screen reader).

17. Links—Link text should make sense when read out of context.

WCAG 2.0: 2.4.4

Blind individuals often get an overview of page content by extracting a list of links. Links such as “Click Here” or “More” will not make sense when read from this list; instead, these links should be expanded to reflect their context, such as “Click here for a list of participants,” or “More about your telephone bill.”

In addition, every link on a page with a unique destination should have a unique name. There may be multiple “Phone” links on a page; these should be expanded to read “Matthew’s Phone” or “Dean Beck’s Phone.” The exception is when there is a matrix where nearby links can provide a context. For example, on a travel site that lists hotels, a user might hear a link to each hotel followed by a “Phone” link; it can be assumed the user will infer that the “Phone” link is associated with the hotel link that precedes it.

18. Automatic Responses—Changing settings or focus should not generate an automatic response from the page.

WCAG 3.2.1, 3.2.2

Assistive technology users need the ability to browse some types of form fields without having a selection made automatically. For example, if they are accessing a pull-down menu, they will usually want to see or hear several options, or will need to use keyboard commands to move through the list until they locate the option they want. If an option automatically activates as soon as it receives focus, this will force users with disabilities to spend an inordinate amount of time browsing. Therefore, the user should be required to perform some activity, such as clicking a “Submit” button or pressing “Enter,” before the page responds to the option receiving focus.

In addition, the unexpected opening of a new window may cause confusion for some assistive technology users. If a new window needs to be opened in response to a user action, the user should receive prior warning. For example, link text might read, “Recipe for Coq Au Vin (opens in new window).”

19. Error Assistance—Help users avoid or correct mistakes.

WCAG 2.0: 3.3.1, 3.3.2, 3.3.3, 3.3.4

A major change between WCAG 1.0 and 2.0 is the addition of guidelines covering error prevention and correction. Level A covers the following topics:
•    Notify the user if they have made an error—e.g., left a required field blank, or put numeric information into a phone number field. A good way to do this is by having a dialog box appear, explaining the problem clearly and concisely, as soon as the user tries to move to another field—this is a more direct way to get the user’s attention. After the dialog box is closed, it’s helpful to have the focus return to the problematic field.
•    Provide clear labels and other instructions. This overlaps with the guidelines on labeling form fields; see topic 10, “Forms,” above.

For Level AA compliance, the following additional guidelines apply:
•    Provide suggestions about correcting errors. For example, if the user types in a misspelled city name, the program could offer suggestions for valid names.
•    Where accurate information is critical—e.g., for banking transactions—users should be able to either reverse their submission, receive feedback on possible input errors, or be allowed to review their information prior to submission.

Level AA compliance

The following guidelines are not currently part of Section 508, but are required for WCAG 2.0 Level AA compliance.

20. Color Contrast—Regular and bitmapped text should have sufficient contrast with the background to ensure legibility.

WCAG 2.0: 1.4.3

In designing color combinations for a web page or graphic, the text and background should differ significantly in both the brightness levels (light colors on a dark background, and vice versa) and hues (colors that are opposite each other on the color wheel provide the best contrast). Light yellow text on a dark purple background works well; light yellow text on a spring green background does not. This will affect legibility for elders as well as people with low vision of all ages.

21. Bitmapped Text—Where possible, actual text should be used instead of bitmapped text.

WCAG 2.0: 1.4.4

Because it is hard to control user preferences for bitmapped text, and because it cannot be accessed by most assistive technologies, actual text should be used where possible. Exceptions include logos and other elements where use of bitmapped text is an essential part of an image.  

22. Navigation—Provide clear ways for users to locate specific pages within a site.

Many websites contain a large number of pages, and it can be confusing for individuals with and without disabilities to know how to navigate to the page they want. Site maps, tables of contents, search functions, and lists of links are all useful methods to provide assistance. The WCAG guideline recommends that at least two of these methods be available on any page within the site.

23. Headers—Use header markup to indicate page hierarchy; do not use it solely for formatting text.

WCAG 2.0: 2.4.6

Page headers (<h1>, <h2>, <h3>, etc.) can be very useful navigation aids for blind individuals. They should be used to create a hierarchy as follows:

•    <h1> Used once on every page to indicate the title; this is often the same as the first part of the <title> tag, e.g., <h1>Financial Aid</h1>. Every page should at a minimum have a <h1> header.
•    <h2> Used to indicate the highest level of subheader. It should seldom if ever stand alone; there should be text underneath it.
•    <h3> Used to indicate the next highest level of subheader. It should always be grouped under a <h2> header and should have text underneath it.

A page with correct header markup might be set up as follows:

<h1> Financial Aid</h1>
<h2> Application  Dates</h2>
<h3> Spring Semester 2011</h3>
<h3>Fall Semester 2011</h3>
<h3>Winter Semester 2012</h3>
<h2>Application Requirements</h2>
<h3>Income Verification</h3>
<h4>Parental Income</h4>
<h4>Applicant Income</h4>


The guideline that covers this also covers providing text labels wherever they might be useful. For example, at the beginning of a form where an asterisk precedes required fields, it’s helpful to provide text such as, “Required fields are marked with an asterisk.”

24. Focus—Ensure that sighted keyboard-only users have a visible means of determining the current page focus.

WCAG 2.0: 2.4.7

When a particular element on a page is receiving focus, browsers usually provide visual indicators such as a dotted-line box around a link or a cursor within a form field. If this does not happen automatically, page authors can use CSS or other means to provide a visual indication of the focus. In addition, authors should not deactivate users’ ability to see the visual indicator.

25. Consistency—Pages within a site should present elements in the same order on each page, and should label identical or similar elements consistently.

WCAG 2.0: 3.2.3, 3.2.4

While these guidelines will benefit any user, they are especially critical for blind people and people with cognitive disabilities, so that they know what to expect from page to page within a site. An easy way to meet these guidelines is to create a site template, so that developers only need to fill in information unique to individual pages. Templates help facilitate consistency among similar elements; e.g., if there is a “Go To Next Page (Page X)” button, then the developer only needs to change the value for “X”. (They can also be used to ensure that accessibility related markup, such as LANG attributes, is included in all site pages.)

Have a question?

Ask an Expert