The following guidelines are just some of the methods used to help make websites accessible and are adapted from the UH Web Accessibility Guidelines web site.
For more extensive information on accessibility, visit The Access Board’s guidelines used by the federal government and the World Wide Web Consortium’s Web Accessibility Initiative.
Provide accurate descriptions for text links.
Reason: Accurate information of where links will lead help users to 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”.
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-graphical browsers (e.g. Lynx), or if graphics are turned off in a browser.
Solution: Use the
ALT label to include descriptive text for images.
<IMG BORDER="0" SRC="pics/surf.jpg" ALT="Sunset Beach on the North Shore of Oahu">
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
Provide a text description for animation.
Reason: Screen readers and text based browsers cannot read animation.
Solution: Use the ALT tag for animated gifs. If Macromedia Flash is used for animation, an accessibility kit is available at: http://www.macromedia.com/software/flash/productinfo/accessibility. You can use this kit 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.
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 need to be properly 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 conjunction with the
<TD> tags. The
<TH> tag is used to signify a column or row headers and the
<TD> tag is used for data cells.
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:
<th scope="col" >January</th>
<th scope="col" >February</th>
<th scope="col" >March</th>
<td scope="row" >Food</td>
<td scope="row" >Gas</td>
<td scope="row" >Electricity</td>
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:
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.
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 style sheet.
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” because they can address different levels of formatting such as different header levels.
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.
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.
<img src="myFunction.gif" alt="image link for starting myFunction">
Another method involves the “title” attribute of the <a> tag. For example:
Use Event Handlers that allow for accessibility.
Reason: Some event handlers require mouse input which create accessibility problems.
Solution: Use event handlers can have been tested for accessibility.
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.
onDblClick – Requires mouse input and can be confusing.
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.
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 only one method call, 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”.
ALT tags (only for browsers that support Java). Put text between
<APPLET CODE=”Appletinventory.class" WIDTH="200", HEIGHT="100">
This applet displays current list of items in stock.
Sun Java Tutorial:
IBM Java Tutorial:
Provide an alternate way to view PDF files.
Reason: Screen readers cannot access PDF files.
Solution: You can make an HTML version, or use Adobe’s online PDF to HTML conversion tool. With the conversion tool, the user submits the URL of the PDF file in a form and an HTML version will be returned immediately within the browser.
Acrobat 5.0 and MakeAccessible plugin. Or you can obtain Adobe Acrobat 5.0 which will allow you to save accessible PDF files from Microsoft Office 2000 or with a free plugin called MakeAccessible, users can make previously made PDF files accessible. This plugin can be downloaded at:http://www.adobe.com/support/downloads/88de.htm.
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 or send email. Forms should be navigable using the Tab key which are commonly used in screen readers.
Use the LABEL tag for forms.
Reason: Its always a good idea to provide alternate means to an online form, however you can make forms accessible to screan readers.
Solution: Use the
<LABEL> 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 screan reader may get confused as to which label to pair the form element resulting in data entered into the wrong element. For example:
<TD><B><LABEL FOR="first"> FIRST NAME:</LABEL> </B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME" ID="first" ></TD>
<TD><B><LABEL FOR="last"> LAST NAME:</LABEL> </B></TD>
<TD><INPUT TYPE="TEXT" NAME="LASTNAME" ID="last" ></TD>
<INPUT TYPE="SUBMIT" VALUE="SUBMIT">
Identify each Frame
Reason: Allows for easier navigation for users with screan 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 screan 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.)
<frame src="navlinks.html" name="navlinks" title="Navigational Links Frame">
<frame src="geninfo.html" name="contents" title="Contents Frame">
Reason: Flash animations are not accessible to screan readers and text browsers. These tools allow for a convenient way to check for accessibility within Dreamweaver and Fireworks.
Solution: Download the Macromedia Flash Accessibility Kit athttp://www.macromedia.com/software/flash/productinfo/accessibility. The kit will allow authors to add descriptions to the animations which will then be accessible to screan readers and text browsers.
Accessibility utilities for Dreamweaver and Fireworks also available at :http://www.macromedia.com/macromedia/accessibility/tools/.
Dreamweaver Accessibility Templates are available for download from:http://www.macromedia.com/macromedia/accessibility/tools/.
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.
Example: Gregg M. Sinclair Library, UHM
Test your Web site using a screen reader and a text based browser.
Reason: For a good indication for accessibility, use the tools people with disabilities use to access web sites.
Solution: Use a screen reader such as IBM Home Page Reader. A 30 day trial version of IBM Home Page Reader can be dowloaded from:
http://www-3.ibm.com/able/hpr.html. Also, use a text based browser such as Lynx.
- Avoid flashing and flickering that range from 4 to 59 flashes per second (Hertz) range.
- If a timed response is requiried, 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 Program.
The Access Board (6/21/2001). Web-based Intranet and Internet Information and Applications.