Section content mobile menu toggleSection Content

Web Accessibility Guidelines and Testing Procedures for UH Websites

The following are guidelines based off of the Web Accessibility Initiative's (WAI) WCAG2.0 Guidelines for buliding accessible web content.

WCAG 2.0 General Guidelines

1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols, or simpler language
1.2 Time-based Media: Provide alternatives for time-based media
1.3 Adaptable: create content that can be presented in different ways without losing information or structure
1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background
2.1 Keyboard Accessible: Make all functionality available from a keyboard.
2.2 Enough Time: Provide users enough time to read and use content
2.3 Seizures: Do not design content in a way that is known to cause seizures
2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are
3.1 Readable: Make text content readable and understandable
3.2 Predictable: Make web pages appear and operate in predictable ways
3.3 Input Assistance: Help users avoid and correct mistakes
4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies

Specifics on these guidelines can be found at

WAI-ARIA Guidelines Cover:

  • AJAX
  • HTML 5
  • Oracle Java
  • Adobe Flash
  • Microsoft Silverlight

More information about the WAI-ARIA guidelines can be found at

Note: Markup validation is not available for WAI-ARIA content. Please make sure you follow the accessibility guidelines and procedures for the platform you are using.

General Rules

The following rules are based on the WAI WCAG 2.0 Web Accessibility Guidelines. Adhering to these rules when creating course content can assist in making course sites more accessible. These guidelines are just some of the methods used to help make websites more accessible:

For more extensive information on accessibility and what you can do to make your website accessible to all, please visit World Wide Web Consortium's Web Accessibility Initiative.

Text Information (top)

Provide accurate descriptions for text links

  • Reason: Accurate information of where links will lead help users navigate your site more effectively.
  • Solution: Provide a clear and concise text descriptor about the nature of the link. Long lists of links should be organized in a logical manner. Avoid text links such as "Click here". Users with a screen readers who jump from link to link or list links will only hear "Click here".

Graphics and Image Maps (top)

Provide a text description for images

  • Reason: Users with screen readers can hear a description of images that have text description. Text descriptions for images can be viewed using non-graphic browsers (e.g. Lynx), or if graphics are turned off in a browser.
  • Solution: Use the ALT label to include descriptive text for images. Example: <A HREF="hawaii/beach.html"><IMG BORDER="0" SRC="pics/surf.jpg" ALT="Sunset Beach on the North Shore of Oahu"></A>

Make unimportant images invisible to the screen reader

  • Reason: Not all images need to be read by a screen reader such as bullets or other "eye-candy".
  • Solution: Use an empty ALT tag.Example: <SRC="bullet.gif" ALT="">

Provide a text description for animation

  • Reason: Screan readers and text based browsers cannot read animation.
  • Solution: Use the ALT tag for animated gifs. If Adobe Flash is used for animation, accessibility guidelines are available at: You can use these guidelines to add a description to an animation made with Flash.

Provide detailed text descriptions for all complex images

  • Reason: Users who cannot view a complex image will benefit more from a detailed description instead of a simple ALT tag.
  • Solution: Provide a link to a description of the image or include descriptive information next to the image.

Use Client-side Image Maps instead of Server-side image maps whenever possible

  • Reason: Client-side image maps allow the author to add ALT tags for the links which will allow screen readers or text based browsers to identify the hot spots. A server-side image map merely provides the coordinates of the hot spots in an image map and the browsers cannot indicate to the user the URL that will be followed when a region of the map is activated.
  • Solution: Provide ALT tags in client-side image maps for each link and if server-side image maps are used, provide redundant text links. Its also common to provide redundant text links for client-side image maps also.

Color (top)

Avoid using color alone to convey information

  • Reason: Using color dependent Web pages will not benefit people who cannot differentiate between certain colors and those with devices that have non-color or non-visual displays. Also, using foreground and background colors that are too close to the same hue may not provide sufficient contrast on monochrome displays or be viewable by people with different types of color deficits.
  • Solution: Make sure color is not used for navigation or interactive purposes. For foreground and background color combinations, make sure there is sufficient contrast for users with color deficits or for black and white monitors.

Tables (top)

Tables need to be proper formatted

  • Reason: Tables which lack row and column headings and specific attributes could prevent users with screen readers from navigating tables properly.
  • Solution: Use the "scope" attribute for columns and rows in conjuntion with the <TH> or <TD> tags. The <TH> tag is used to signify a column or row headers and the <TD> tag is used for data cells. scope="col" scope="row". By using the scope attribute, the text in the cell will be associated with every cell in the column or row. The following is an example using the scope attribute:<table>
    <th> </th>
    <th scope="col" >January</th> <th scope="col" >February</th> <th scope="col" >March</th> <th scope="col">April</th></tr>
    <tr> <td scope="row" >Food</td> <td>200.00</td> <td>150.00</td> <td>220.00</td><td>175.00</td>
    <tr> <td scope="row" >Gas</td> <td>30.00</td> <td>40.00</td> <td>35.00</td> <td>32.00</td>
    <tr> <td scope="row" >Electricity</td> <td>70.00</td> <td>75.00</td> <td>60.00</td> <td>65.00</td>
    </table> Note: Notice how the "scope="row"" attribute was used with the <TD> tag. The <TH> tag could also have been used. The following is the resulting table:

January February March April
Food 200.00 150.00 220.00 175.00
Gas 30.00 40.00 35.00 32.00
Electricity 70.00 75.00 60.00 65.00

Note: Some recommend using the "Summary" attribute of the table tag, however the Access Board does not recommend using the "Summary" attribute because major screen readers do not support this attribute. If you want to summarize your table, you may place the description next to the table or in the body of the table. You may consider using the "Caption" tag for this.

Style Sheets (top)

Use Style sheets to structure layout and properties of content

  • Reason: Style sheets can be used to control color, font, sizes and spacing for an entire web site. This reduces the amount of html code in a web site making it easier for screen readers to navigate. It also makes it easier to change a whole web site. For example, if you need to change the size of headings or fonts, all you need to do is change the properties in the stylesheet.
  • Solution: Use Internal style sheets (placing the style sheets in the "head" tag of an HTML document or external style sheet, (style sheet is in a separate file). Often, style sheets are referred to as "Cascading Style Sheets" which are templates, very similar to templates containing a set of rules specifying the rendering of various HTML elements. These templates describe how a document is presented on the screen or when printed out.

Make sure a web page is accessible without a style sheet

  • Reason: Some assistive technology devices may have trouble with style sheets or a browser may not support it.
  • Solution: Test to make sure your web site can be viewed logically without style sheets.

Audio and Video Files (top)

Provide alternative for audio files

  • Reason: Users who have hearing loss or have computers with no audio capability cannot benefit from audio files.
  • Solution: Provide a descriptive text for the audio link and transcription of the audio file.

Provide alternatives for video files

  • Reason: Users who cannot see, have low vision, or have computers unable to show video cannot benefit from video files. Deaf users or users that own computers with no sound capability cannot benefit from audio coming from video files.
  • Solution: Provide audio descriptions, transcripts, or captioning for video files.

Java, Javascript and Applets (top)

When using JavaScript, provide functional text equivalence for screen readers

  • Reason: If functional text is provided describing the action occurring within the JavaScript, the screen reader can read the information to the user. Without functional text, the screen reader will read the JavaScript itself resulting in a meaningless jumble of numbers and letters.
  • Solution: One method is to include the Alt tag with a JavaScript. For example: <a href="javascript:myFunction();"><img src="myFunction.gif" alt="image link for starting myFunction"></a>.Another method involves the "title" attribute of the <a> tag. For example: <a title="this link starts myFunction" href="javascript:myFunction();"><img src="myFunction.gif"></a>.

Use Event Handlers that allow for accessibility

  • Reason: Some event handlers require mouse input which create accessibility problems.
  • Solution: Use event handlers that have been tested for accessibility.

The following JavaScript event handlers have been found to work with assistive technology:
onClick - State clearly on the page what will occur with this event handler. Don't use onClick for form elements that include several options (e.g., select lists) unless absolutely necessary.
onLoad and onUnload - Since these event handlers are not triggered by user input, accessibility is not a problem.

Avoid using these JavaScript event handlers:
onDblClick - Requires mouse input and can be confusing.
onMouseDown and onMouseUp - Also require mouse input. Use the onClick event handler instead.
onChange - Use only if you associate it with a link or button that is adjacent to a tag.

Other JavaScript handlers that don't usually pose a problem with AT, but don't provide useful information to them and could create confusion. These include:
onMouseover and onMouseOut, onBlur and onFocus.

Java Techniques

The Java 2 Platform features built-in accessibility support that allows developers to produce applications that work with AT. A component uses the Java Accessibility API extension by using the "Accessible" interface. This is done with, getAccessibleContext(), which returns an instance of AccessibleContext specific to the component allowing it to become accessible.

Use the AccessibleName and AccessibleDescription on all components. The AccessibleName property is the key to make objects usable by a person with a disability. Use a label (no more than two words) that describes the purpose of the component. An AccessibleDescription can also be added if the purpose of the component is not obvious from its name. This will provide more information for the assistive technology device. For example, a button for Enter could have an AccessibleName of "Enter button". A Cancel button could have an AccessibleName of "Cancel button". The cancel button can also have an AccessibleDescription of "Ignore entry and close dialog box".


Use ALT tags (only for browsers that support Java). Put text between <Applet> or <Object> tags. Example: <APPLET CODE=?Appletinventory.class" WIDTH="200", HEIGHT="100">
This applet displays current list of items in stock.


Sun Java Tutorial:
Trace Center:

Accessible PDFs (top)

Provide an alternate way to view PDFs, or create them to be accessible.

Forms (top)

Include an alternative to online forms

  • Reason: Forms can be difficult to for people using screen readers and may not be supported by all browsers.
  • Solution: Allow the user to print out the form, send email, phone or FAX. Forms should be navigable using the Tab key which are commonly used in screen readers.

Use the LABEL tag for forms (Not necessary for simple forms where all the form elements are adjacent or right under labels).

  • Reason: Its always a good idea to provide alternate means to an online form, however you can make forms accessible to screen readers.
  • Solution: Use the tag and the associated "FOR" attribute to associate form elements with specific labels. The label tag will identify the form element (e.g. text area, check box etc.) with a label. Also use the "FOR" attribute and make it equal the item in the "ID" attribute which will "tie" the form element to the associated label. Without the Label tag, a screen reader may get confused as to which label to pair the form element resulting in data entered into the wrong element. For example:<FORM>

<TD><B><LABEL FOR="first"> FIRST NAME:</LABEL> </B></TD>
<TD><B><LABEL FOR="last"> LAST NAME:</LABEL> </B></TD>

Frames (top)

Identify each Frame

  • Reason: Allows for easier navigation for users with screen readers or text browsers.
  • Solution: At the top of each frame, have a descriptive title such as "Navigation Links".

Also use the "title" attribute for each Frame

  • Reason: A person using a screen reader or a text based browser can get disoriented when frames have no title attributes. This is an additional measure to the above technique because it will allow the screen reader or text browser to identify the frames by name.
  • Solution: Use the "title" attribute to title frames (e.g. navigation frame, content frame etc.) Example: <frame src="navlinks.html" name="navlinks" title="Navigational Links Frame"> <frame src="geninfo.html" name="contents" title="Contents Frame">

Use Adobe Flash, Dreamweaver and Fireworks Accessibility Tools (top)

  • Reason: Flash animation's are not accessible to screen readers and text browsers.
  • Solution: For accessibility solutions when using Adobe products please refer to Adobe's Accessibility Resource Center at:

Allow user to skip navigation links (top)

  • Reason: People using screen readers will repeatedly hear the same navigation links for each page before reaching the contents of the page. People using text based browsers will see the same links on each screen and will need to "page down" each time to reach the contents.
  • Solution: Create a simple link at the top left of the page that reads something like "Skip Navigation Links". Do this for all pages except the welcome page.

Testing Your Web Site (top)

1. Test markup against WCAG 2.0 Guidelines using or Markup should pass with A or better.

2. Make any changes to markup, if needed, based on the results from the test. Test again if necessary, and then proceed to the next step.

3. Test with a screen reader using JAWS if available or NVDA, which is free from for readability.

4. Check navigation with keyboard. Best tested by using a screen reader, your computer monitor turned off, and your speakers/headphones turned on.

5. Check for usability/readability when zoomed into 200-300%.

Other Recommendations (top)

  • Avoid flashing and flickering that range from 4 to 59 flashes per second (Hertz) range.
  • If a timed response is required, the user shall be notified and given the opportunity for more time.
  • Create a consistent layout for all pages.
  • Create a consistent navigation design.
  • Downloadable files should be listed in a single location.
  • Explain acronyms and abbreviations.


Stewart, R. (1999). Designing and using information technology accessible to persons with disabilities: Web sites, distance education and adaptive technology. Corvallis, OR: Oregon State University, Technology Access ProgramThe Access Board (6/21/2001). Web-based Intranet and Internet Information and Applications.