Web Designer Guide (Implementation Date 1/1/2007)

Accessibility Issue:

Non-text elements (images, java applets, flash files, video files, audio files, plug-ins, etc.) are not accessible by screen readers, talking browsers and text browsers. 

Solution:

All non-text elements must have alt tag descriptions that convey the purpose of the intended meaning of the object. The idea of the alternate text is to provide a textual equivalent for pictures (images) that convey the same thing as is communicated to a sighted user seeing the image.  Screen readers and talking browsers cannot do anything with an image itself -- they will announce the alternative text instead.  If an image conveys no information or is redundant, specify that with null alt-text, alt="".  You do not have to include a reference to the fact that something is a link, for example, alt="link to Home".  Text browsers and screen readers inform their users when they encounter a link.

Alternative text should be short and simple, but sometimes you may need to provide more explanation or content than is suitable for alt-text.  In these cases, you can use the LONGDESC attribute of the IMG element.  The LONGDESC attribute points to the URL of a separate description file that contains information conveyed by the image.

For example:

Accessibility Issue:

If information is audio, a person who is deaf or hard of heading cannot access content unless provision is made for a visual presentation of audio content.

Solution:

Audio content must include a transcript. A transcript of audio content is a word-for-word textual representation of the audio, including descriptions of non-text sounds like "laughter" or "thunder." Transcripts of audio content are valuable not only for persons with disabilities but in addition, they permit searching and indexing of that content which is not possible with just the audio.
 

Accessibility Issue:

If content is pure video or multimedia (audio-visual), a blind person or a person with severe vision loss will miss the message without the important information in the video being described.

Solution: 
Multimedia content must include synchronized audio, that is, it must be captioned.  Video and multimedia content must also include a transcript.  The transcript may also include video descriptions (e.g. descriptions of the scene, graphics being displayed, and other visual elements important to the comprehension).   

Accessibility Issue:

When colors are used as the sole method for identifying screen elements or controls, person who are color blind as well as those people who are blind or have low vision may find the web page unusable.

Solution:

When color is used to convey important information, also use context and markup to convey the same information.  For example, use graphic symbols such as underlining, asterisks, or borders to identify special content (including links).  Label buttons and navigation bars with text.

Accessibility Issue:

If foreground and background colors are too close to the same hue, they may not provide sufficient contrast for people with different types of color deficits or for people using monochrome displays.

Solution: 

Choose highly contrastive colors for the foreground and background.
 

Accessibility Issue:

Some people use browsers that do not support cascading style sheets or they may have style sheets turned off so they can enable a style sheet of their own.

Solution:

Check your page with style sheets turned off.

Accessibility Issue:

When cascading style sheets are used to simulate structural markup, your page will not be "readable" when a user has style sheets turned off.  Even with style sheets turned on, assistive technology will not find structural elements that it needs to help navigate the content.

Solution:

Do not use substitute style changes for the structural elements of HTML like headings, paragraphs and lists.

For example:

HEAD style

HEADING tag

Accessibility Issue:

An image map is a picture on a web page that provides different links to other web pages, depending on where a user clicks.  Client-side image maps are accessible because each area can have alt text.  Then assistive technology just provides the list of links for the map given by their alternative text.  For server-side image maps, the client browser just sends the coordinates of a mouse click to the server where calculations are made and the appropriate page sent back to the client. Because of this essentially visual (and mouse) method of selecting a new page, there is no way to make server-side image maps accessible.

Solution:

When regions can be defined with an available geometric shape, use client-side image maps and be sure to provide alternative text for each AREA of the map.

For example:

Accessibility Issue: 
With server-side image maps, "active regions" in the picture only display a set of coordinates. Browsers cannot indicate to the user the URL that will be followed when a region of the map is activated.

Solution

Server-side image maps should only be used when regions cannot be defined with an available geometric shape and must include a redundant text link.

For example:  Using the client-side image example above, the equivalent text links, namely, "Home," "News," "Services," "Comments," and "Search" could be located at the bottom of the page. The alt text for the image should advise the user of these links: alt="Navigation Bar (text navigation at bottom)".
 

When you come across a data table, you can scan the table to get a quick sense of what it represents; you can't do that when you are reading a table linearly.

Solution:

On simple data table, use CAPTION element to associate the title of a table with the table itself.

For example:

When a table is more complicated,  use the SUMMARY attribute to provide a summary of what the table presents.  It should provide an orientation for someone who listens to the table.

For example:

Accessibility Issue:

Large tables of data can be difficult to interpret if a person is using a non-visual means of accessing the web.  Users of screen readers can easily get "lost" inside a table because it may be impossible to associate a particular cell that a screen reader is reading with the corresponding column headings and row names.

Solution:
The first row of each table should include column headings.  The column heading are inserted in the <TH> tags along with a the scope="col" attribute.  Similarly, each cell in the first cell in the first column of every data table should include uniquely identifying information about the content of each row in the table along with a scope="row" attribute.

For example:

Note:  Do not create layout tables with a summary attribute, caption element,  or column or row headers. 
 

Accessibility Issue:

When a data table is more complicated than just simple columns and rows, assistive technology has difficulty determining the header information.

Solution:

Define the header using the "id" attribute in the <TH> element.  Then specify the correct header using the "headers" attribute in the <TD> element of each data cell.

For example:

Accessibility Issue:

Frames provide a means of visually dividing the computer screen into distinct areas that can be separately rewritten.  Unfortunately, frames can also pre sent difficulties for users with disabilities when those frames are not easily identifiable to assistive technology.  When a text browser opens a frame site, it can only work with one page at a time.  So text browsers offer a list of frames from which the user can select.  Therefore, the frames must be meaningfully identified.  

Solution:

Every page should have a title as given in the TITLE element which is part of HEAD content:

And for each frame page:

The main frame page should identify each frame using the NAME and TITLE elements which are part of the FRAME content:

Each frame page should include text within the body of each frame that clearly identifies the frame.

Accessibility Issue:

People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range as well as quick changes from dark to light (like strobe lights).  Some people with cognitive or visual disabilities are unable to read moving text quickly enough or not at all.  Screen readers are unable to read moving text.

Solution: 

Use moving content images only when necessary to interpreting content.  Ensure that the user can pause or stop any moving, blinking, scrolling, or auto-updating objects or pages.  If you must have movement on the page, use style sheets with scripting to create the effect that you want.  This allows users to turn off or override it more easily.  Do not use BLINK or MARQUEE elements.

Accessibility Issue:

When functional text is not provided with a script, a screen reader will often read the content of the script itself in a meaningless jumble of number and letters.  Although this jumble is text, it cannot be interpreted or used.
 

Solution: 
For example:

< href="javascript:myFunction();"><img src="myFunction.gif" alt="picture link for start myFunction"></a>

Without the alt tag, the screen reader would read "javascript myfunction".

Note: Many people use older browsers on text browsers that do not support JavaScript.  If JavaScript is playing any essential role on your web page, those people will not have access to your page content.  The Web Accessibility Initiative guideline for JavaScript is direct and simple. It is OK to use JavaScript so long as its application, what it does, is not essential. It is easy to test against the WAI guideline. Turn off JavaScript and test your Web site.  In contrast, the Section 508 standard, recognizing the need for JavaScript in general, allows JavaScript so long as the information is accessible, i.e., readable with assistive technology. This standard is not direct and it is not simple. Even when evaluating your site relative to Section 508 accessibility, it may be necessary to test with JavaScript turned off.
 

Accessibility Issue:

Web authors frequently rely on other applications beyond those available in a browser to display specialized content.  It is the responsibility of the web author to insure that these applications are compliant with MWAS and available to assistive technology.

Solution:

Verify that the required plug-in is compatible with assistive technology or offer the content in an alternate format.  Provide a link to the download page of any necessary plug-in on each page it is required to view information or perform tasks.

Accessibility Issue:

The accessibility issue for forms is whether or not users with disabilities, especially those who are blind or visually impaired, can determine the purpose of a specific form control and interact with it. For example, a screen reader user will be aware that a text entry field has focus, but may not know what information to type there. Screen readers try to guess which text corresponds to the on-screen prompt for a given control. Often they guess correctly, but sometimes they are wrong.

Solution:

Place labels immediately adjacent to form elements.  If you use table to layout forms, put both the form label and element in the same cell.

Always use the LABEL element to associate the prompting text with the INPUT element.

For example:

Use the TITLE attribute on the INPUT element to specify the purpose of the control if the on-screen text is not adequate or is dispersed.

For example:

If you use JavaScript to trigger the forms action, be sure that you use a triggering event that does not require the mouse.  Use the ACCESSKEY attribute in the INPUT element.

For example:

Use the TABINDEX attribute to create a logical tab order for navigating the form.

For example:

Accessibility Issue:

Web developers routinely place a host of routine navigational links at a standard location – often across the top, bottom, or side of a page. If a non-disabled user returns to a web page and knows that he or she wants to view the contents of that particular page instead of selecting a navigation link to go to another page, he or she may simply look past the links and begin reading wherever the desired text is located. For those who use screen readers or other types of assistive technologies, however, it can be a tedious and time-consuming chore to wait for the assistive technology to work through and announce each of the standard navigational links before getting to the intended location.
 

Solution:

When repetitive navigational links are used, there must be a mechanism for users to skip repetitive navigational links.  Create a visible or invisible in-page link.  You can make it invisible by using a style sheet tot color the text the same color as the page background or by using a transparent image link.  Place an anchor/bookmark in the page immediately before the start of the content.  Link the skip navigation text or image to that anchor.  The link text or image ALT tag should be "skip navigation".

Accessibility Issue:

Web pages can be designed with scripts so that the web page disappears or "expires" if a response is not received within a specified amount of time. Sometimes, this technique is used for security reasons or to reduce the demands on the computer serving the web pages. Someone's disability can have a direct impact on the speed with which he or she can read, move around, or fill in a web form. For instance, someone with extremely low vision may be a slower-than-average reader. A page may "time out" before he is able to finish reading it. Many forms, when they "time out" automatically, also delete whatever data has been entered. The result is that someone with a disability who is slow to enter data cannot complete the form.

Solution:

When a timed response is required, the user shall be alerted via a prompt and given sufficient time to indicate whether additional time is needed.
 

Accessibility Issue:

Links that open in new windows can be extremely disorienting to users of assistive technology.  These links break the "BACK" and "HISTORY" list.  Screen readers may or may not indicate a new window has opened, causing links to appear "dead" -- e.g. nothing appears to happen when the link is activated because the new window opens without notice.

Solution:

Carefully consider when to use links that open in new windows. Generally, there is little advantage to forcing users to keep your site in an open window unless you are certain they will need to return to your site after viewing other pages (e.g. when leaving a form to get more information on required inputs, users may then be expected to return to the form page without the form being reloaded and entered data being cleared). Identify any links that open in a new window using a referenced symbol or plain text.

For example:

Find out more information about this topic (opens in new window).
 

Accessibility Issue:

Link text is frequently read out of context by users of assistive technology. So a link that reads "Click here for information on this topic" in the body of the page, appears as only "Click here" in a link list. Multiple "Click here" phrases on a page makes the process even more confusing.

Solution:

Choose link text that makes sense out of context and describes where the link leads.  Instead of: "Click here for more information", use "Get more information about us" or  "Get more information about us".
 

Accessibility Issue:

When compliance cannot be accomplished in any other way, a text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of these standards.

 

Solution:

When compliance cannot be accomplished in any other way,  create a text-only page.  Text-only pages must contain equivalent information or functionality as the primary pages. Also, the text-only page shall be updated whenever the primary page changes.  Clearly identify the availability of alternate version and make the alternate version easy to access.