Improve Your Pages

(a) A text equivalent for every non-text element shall be provided (e.g., via <alt>, <longdesc>, or in element content). 

The <alt> text tag provides a title or descriptive phrase about the image it accompanies. This is essential for users of reader software who are vision impaired and it is valuable for users of graphical browsers who have "load images" turned off. It is also useful for users of text-only WWW tools like Lynx. The <longdesc> tag can be essential when an image conveys important information such as what about the image represents a discovery if the image is a science result image.

Also See: Paragraph A Description and ALT Tags

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

In a multimedia presentation, like a movie or animation, it is important to provide people who cannot see the screen with alternatives for the visual track. These alternatives include both captions for spoken word and auditory descriptions of relevant action taking place on the screen. These alternatives should be synchronized with the action taking place on the screen.

Also any dynamic changes which occur based on multimedia content (either in a <frame>, <img>, <object>, or <script>) must also update the "alt" element when it changes.

Also See: Paragraph B Description

(c) Web pages shall be designed so that all information conveyed with color is also available without color.

Thirty percent of all males suffer from some form of color deficiency rendering colors as grays or spreading one color across several others.   Choose text and background colors to provide maximum contrast. Contrast is also very important for individuals who can see but have reduced vision. Good design also refers to the ability of reader software to properly parse a page correctly left to right and up to down. For example see Good primer on Color Blindness and others.

There are two simple ways of testing a web page to determine if this requirement is being met: by either viewing the page on a black and white monitor, or by printing it out on a black and white printer. Both methods will quickly show if the removal of color affects the usability of the page.

Also see Checkpoint Two: Don't Rely on Color Alone by Kynn Bartlett and Paragraph C Description

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

Stylesheets present a double-edged sword: Only the latest browsers support the specification and when using them the text still needs to be able to be parsed correctly by reader software.

For good access it is critical that designers ensure that their web pages do not interfere with user-defined style sheets. Style sheets can enable users to define specific viewing preferences to accommodate their disability. For instance, users with low vision may create their own style sheet so that, regardless of what web pages they visit, all text is displayed in an extra large font with white characters on a black background.

To see how a site will look without style sheets, visit Delorie Web Page Backward Compatibility Viewer.

Also See: Paragraph D Description and StyleSheets

(e) Redundant text links shall be provided for each active region.

Most sites have moved away from server-side image maps.   But if you use them redundant text links are necessary to provide access to the page for anyone not able to see or accurately click on the map.

Also See: Paragraph E Description

(f) Client-side image maps shall be provided instead of server-side images maps except where the regions cannot be defined with an available geometric shape.

Modern browsers support client-side image maps, with the addition of <alt> text tags for the image hot spots, Assistive technology readers can provide additional clues.  However, if the user has "load images" turned off, the only approach is to provide alternative links elsewhere on the same page.

Also See: Paragraph F Description

(g) Row and column headers shall be identified for data tables.

Using row and column headers becomes crucial when a table is larger than two columns or two rows.   Without the headers, Assistive technology such as reader software can only recite the table contents with no reference to what that column or row pertains to.  For more information see the Data Tables Page.

Also See: Paragraph G Description

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

Complex table structures may be difficult to understand when read by adaptive technologies. By marking a table with the appropriate tags, browsers will be able to explain and represent a context of the data found within the table.

For complex tables decide how you are going to associate data cells with headers. There are three approaches: headers, scope, and axis. They are not incompatible with each other, so you can get pretty complex.

Additional information such as <summary> and <scope> can be applied to data tables to render their contents and intent meaningful to users of Assistive technology.  <Scope>, in particular, can be very useful for column headers.  

For more information see the Data Tables Page and Also See: Paragraph H Description

(i) Frames shall be titled with text that facilitates frame identification and navigation.

A good way to accomplish this requirement is to include text within the body of each frame that clearly identifies the frame. For instance, in the case of the navigation bar, a web developer should consider putting words such as "Navigational Links" at the beginning of the contents of the frame to let all users know that the frame depicts navigational links. Providing <title> like this at the top of the contents of each frame will satisfy these requirements.

Also, with the, <name> and <longdesc> tags, frames can be made more navigable for reader software.

Also see: Checkpoint Twelve: Title Your Frames by Kynn Bartlett and Also See: Paragraph I Description

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Flicker and continuous motion (as from applets or javascripts or from refreshes) can cause seizures in individuals with photosensitive epilepsy.  Content developers should refrain from an overuse of time-sequenced elements. If used, the timing should be longer than half-a-second. Also, if you must implement this technique, provide warning for users that screen flickering will be encountered. You may wish to provide a non-flicker alternative or a button to control and/or stop the effect.

Also See: Paragraph J Description

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

There may be times when you are not able to comply fully with accessibility guidelines. If these cases, it is acceptable to link to a "text-only" or simplified page to provide access. It is important, however, that these pages remain updated and that they provide equal access to information.

Content developers should only resort to alternative pages when other solutions fail.  An out-of-date page may be as frustrating as one that is inaccessible since, in both cases, the information presented on the original page is unavailable. &. Before resorting to an alternative page, reconsider the design of the original page.

Also See: Paragraph K Description

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by Assistive technology.

The easiest method to provide this accessible alternative is to write HTML code which includes the <noscript> tag.  Other options include ensuring that dynamic content and refreshes can be made or are accessible.

Many web pages use scripts of some sort, whether it be to program buttons, or present dynamic data like date and time. Several browsers, including Assistive technologies, do not currently support these technologies. To address this issue, make sure that any scripts or applets do not provide essential information that would render the site unusable if the script or applet did not run OR if the content contained in the script were not "read" by Assistive technologies.

Button rollovers are nice and add an interactive feel to the site, but if they did not work, would the site remain useful? For instance, a button rollover presents addition menus, which are not replicated elsewhere on the page, would be a problem. If an onMouseover element does not contain any important information, then there is no consequence for accessibility. If this scripted event reveals important information, then a keyboard-accessible alternative is required.

For more info see the scripts section of the general accessibility page and Also See: Paragraph L Description

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

If applets or other elements that require plug-ins are used on a website, make sure that the required plugin is: (1) directly available i.e., a link is provided to a disability-accessible page where the plug-in can be downloaded, and (2) the plug-in is compliant with Assistive technologies. If not, provide alternative means of accessing equivalent content.

For example if you publish documents on-line in PDF format, you should inform users in plain text that PDF is being used, and explain that special software (Adobe Acrobat Reader) is required to view the documents. You should also indicate that an accessible plug-in also exists which will allow access to the documents by persons using adaptive technology for screen-reading. This link will take you to Adobe System's Access page which describes the Access plug-in. You can use the following:

This is an acrobat PDF file. If you do not have acrobat you can download the arobat viewer from adobe. This download is for people who do not have Acrobat installed on their computers. It allows you to open and view a PDF file. Additional Adobe free tools are available to assist visually impaired users at access.adobe.com.

For information on PDF and PowerPoint see the Plugins and applets section of the general accessibility web page.

Also objects and data which require plug-in applications can be presented in HTML code in a nested manner such that, if the user's browser can't display the topmost data type, it will attempt to display equivalent data type in the object specification.  

Also See: Paragraph M Description

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

Forms can be quite difficult to navigate with adaptive technologies if they are not laid out in a predictable and consistent manner. All form controls should have text labels adjacent to them. Furthermore, form elements should also have labels associated with them in the markup.

The first rule of thumb is to place labels adjacent to input fields, not in separate cells of a table. For the web developer who does not wish to place form elements immediately adjacent to their corresponding titles, the HTML 4.0 specification includes the <LABEL> tag that lets web developers mark specific elements as "labels" and then associate a form element with that label. There are generally two ways to use the label tag: explicit labels and implicit labels.

HTML 4.0 introduced a number of new features like the following that can make FORMS more accessible. Among these are:

• Label
• Tabindex
• Fieldset and Legend
• Accesskey
• Optgroup

If you make a form and use a TABLE to layout the FORM components (fields, buttons, menus, etc.) verify is can be linearized and that the label placement is correct.

The key to accessible forms is for a person using assistive technology to be able to identify the purpose of any form control element and to be able to manipulate it.

Also See: Paragraph N Description and Forms

Many websites use top or side navigation to lead people to important parts of their web site. These links usually appear on many or all pages in the site. People who use adaptive technologies such as screen readers will need to read through all of these links each time they go to a page. By placing either an invisible image or a text link which skips the navigation, you will allow users with screen reading technologies to skip directly to the content.

There are a number of methods of facilitating navigation for users of assistive technology.  Be consistent in page-to-page design, designers can provide a jump-link to bypass a series of links on a page similar to the "back to top" used in long pages, when using multiple links close together, separate the links so the reader software can parse it correctly.  Links should be referenced with text which make sense if a user if link-jumping.  Also, consider adding a site map, which is useful to nearly everyone.

The "skip navigation" provision of the Section 508 Standards is related to WCAG a checkpoint, but the Section 508 standard is specific and direct.

Also See: Paragraph O Description

People with cognitive disabilities will need to be made aware that a response is timed to prepare themselves. For example in plain text state what the time limit is and if a user needs more time provide a reset button. Not in WCAG.

Also See: Paragraph P Description