This appendixis an excerpt from the Guide to the Section 508 Standards for Electronic and Information Technology, Subpart B – Technical Standards, Section 1194.22. This is the only section that is relevant to web developers/designers.
Updated: June 21, 2001
These provisions of the standards provide the requirements that must be followed by Federal agencies when producing web pages. These provisions apply unless doing so would impose an undue burden.
The key to compliance with these provisions is adherence to the provisions. Many agencies have purchased assistive software to test their pages. This will produce a better understanding of how these devices interact with different coding techniques. However, it always should be kept in mind that assistive technologies, such as screen readers, are complex programs and take extensive experience to master. For this reason, a novice user may obtain inaccurate results that can easily lead to frustration and a belief that the page does not comply with the standards.
For example, all screen reading programs use special key combinations to read properly coded tables. If the novice user of assistive technology is not aware of these commands, the tables will never read appropriately no matter how well the tables have been formatted.
A web site will be in compliance with the 508 standards if it meets paragraphs (a) through (p) of Section 1194.22. Please note that the tips and techniques discussed in the document for complying with particular sections are not necessarily the only ways of providing compliance with 508. In many cases, they are techniques developed by the Board, the Department of Education, and the Department of Justice that have been tested by users with a wide variety of screen reader software. With the evolution of technology, other techniques may become available or even preferable.
A text equivalent means adding words to represent the purpose of a non-text element. This provision requires that when an image indicates a navigational action such as "move to the next screen" or "go back to the top of the page," the image must be accompanied by actual text that states the purpose of the image. This provision also requires that when an image is used to represent page content, the image must have a text description accompanying it that explains the meaning of the image.
HTML Source Code: <img src="art/logo-green.gif" alt="Access Board Logo">
The text information associated with a non-text element should, when possible, communicate the same information as its associated element. For example, when an image indicates an action, the action must be described in the text. The types of non-text elements requiring actual text descriptions are limited to those elements that provide information required for comprehension of content or those used to facilitate navigation. Web page authors often utilize transparent graphics for spacing. Adding a text description to these elements will produce unnecessary clutter for users of screen readers. For such graphics, an empty alt attribute is useful.
Example of source code: <img src="transparent.gif" alt="">
A non-text element is an image, graphic, audio clip, or other feature that conveys meaning through a picture or sound. Examples include buttons, checkboxes, pictures and embedded or streaming audio or video.
HTML Source Code: <img src="art/logo-green.gif" alt="Access Board Logo">
This provision requires that when audio presentations are available on a multimedia web page, the audio portion must be captioned. Audio is a non-textual element, so a text equivalent of the audio must be provided if the audio is part of a multimedia presentation, Multimedia includes both audio and video. If the presentation is audio only, a text transcript would meet this requirement.
There are several ways of providing textual information so that it can be recognized by assistive technology devices. For instance, the <img> tag can accept an alt attribute that will enable a web designer to include text that describes the picture directly in the <img> tag.
HTML source code:
<img src="image/ab_logo1.gif"
alt="The Architectural and Transportation Barriers Compliance
Board emblem - Go to Access Board website">Similarly, the <applet> tag for Java applets also accepts an alt attribute, but it only works for browsers that provide support for Java. Often, users with slower Internet connections will turn support for Java applets off. A better alternative for providing textual descriptions is to simply include the alternative text between opening and closing <applet> or <object> tags. For instance, if a web designer wanted to include an applet called MyCoolApplet in a web page, and also include a description that the applet shows a stock ticker displaying the current price of various stocks, the designer would use the following HTML coding for example:
<applet code="MyCoolApplet.class" width="200", height="100">
// This applet displays current stock prices for many popular stocks.
</applet> Finally, yet another way of providing a textual description is to include it in the page in the surrounding context:
<p>Below is a picture of me during my great vacation!</p>
<img src="pictureofme.jpg"> Captioning for the audio portion and audio description of visual information of multimedia presentations are considered equivalent alternatives. This provision requires that when an audio portion of a multimedia production is captioned, as required in provision (a), the captioning must be synchronized with the audio. Synchronized captioning would be required so someone reading the captions could also watch the speaker and associate relevant body language with the speech.
No, because it is not multimedia. However, since audio is a non-text element, a text equivalent, such as a transcript, must be available. Similarly, a (silent) web slide show presentation does not need to have an audio description accompanying it, but does require text alternatives to be associated with the graphics.
Yes, this would qualify as a multimedia presentation and would require the speech to be captioned.
Example:
When colors are used as the sole method for identifying screen elements or controls, persons who are color-blind as well as those people who are blind or have low vision may find the web page unusable.
No, this provision does not prohibit the use of color to enhance identification of important features. It does, however, require that some other method of identification, such as text labels, must be combined with the use of color. This provision addresses not only the problem of using color to indicate emphasized text, but also the use of color to indicate an action. For example, a web page that directs a user to "press the green button to start" should also identify the green button in some other fashion than simply by color.
This Illustration is a variation of the actual image published by the U.S. Access Board. To view the published illustration, visit www.access-board.gov/sec508/guide/1194.22.htm#(c).
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.
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. If designers set up their pages to override user-defined style sheets, people with disabilities may not be able to use those pages. For good access, therefore, it is critical that designers ensure that their web pages do not interfere with user-defined style sheets.
In general, the "safest" and most useful form of style sheets are "external" style sheets, in which the style rules are set up in a separate file. An example of an external style sheet is:
Example of source code: <link rel="stylesheet" type="text/css" href="section508.css">
An "image map" is a picture (often an actual map) on a web page that provides different "links" to other web pages, depending on where a user clicks on the image. There are two basic types of image maps: "client-side image maps" and "server-side image maps." With client-side image maps, each "active region" in a picture can be assigned its own "link" (called a URL or "Uniform Resource Locator") that specifies what web page to retrieve when a portion of the picture is selected. HTML allows each active region to have its own alternative text, just like a picture can have alternative text (see §1194.22(a)). By contrast, clicking on a location of a server-side image map only specifies the coordinates within the image when the mouse was depressed. The ultimate selection of the link or URL must be deciphered by the computer serving the web page.
When a web page uses a server-side image map to present the user with a selection of options, browsers cannot indicate to the user the URL that will be followed when a region of the map is activated. Therefore, the redundant text link is necessary to provide access to the page for anyone not able to see or accurately click on the map.
Unlike server-side image maps, the client-side image map allows an author to assign text to image map "hot spots." This feature means that someone using a screen reader can easily identify and activate regions of the map. An explanation of how these image maps are constructed will help clarify this issue.
Creating a basic client-side image map requires several steps:
<img> tag. To identify it as a map, use the usemap attribute.<map> tag is a container tag that includes various <area> tags that are used to identify specific portions of the image.Use <area> tags to identify map regions. To identify regions within a map, simply use <area> tags within the <map> container tags. Making this client-side image map accessible is considerably easier to describe: simply include the alt attribute and area description inside each <area> tag. The following HTML demonstrates how to make a client-side image map:
<img src="navbar.gif" border="0" usemap="#Map">
<map name="Map">
<area shape="rect" coords="0,2,64,19" href="general.html"
alt="information about us">
<area shape="rect" coords="65,2,166,20" href="jobs.html"
alt="job opportunities" >
<area shape="rect" coords="167,2,212,19" href="faq.html"
alt="Frequently Asked Questions">
<area shape="rect" coords="214,2,318,21" href="location.html"
alt="How to find us">
<area shape="rect" coords="319,2,399,23" href="contact.html"
alt="How to contact us">
</map>Paragraphs (g) and (h) permit the use of tables, but require that the tables be coded according to the rules of the markup language being used for creating tables. 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. For instance, assume that a salary table includes the salaries for federal employees by grade and step. Each row in the table may represent a grade scale and each column may represent a step. Thus, finding the salary corresponding to a grade 9, step 5 may involve finding the cell in the ninth row and the fifth column. For a salary chart of 15 grade scales and 10 steps, the table will have at least 150 cells. Without a method to associate the headings with each cell, it is easy to imagine the difficulty a user of assistive technology may encounter with the table.
Section 1194.22 (g) and (h) state that when information is displayed in a table format, the information shall be laid out using appropriate table tags as opposed to using a preformatted table in association with the <pre> tag. Web authors are also required to use one of several methods to provide an association between a header and its related information.
Using the scope attribute is one of the most effective ways of making HTML compliant with these requirements. It is also the simplest method to implement. The scope attribute also works with some (but not all) assistive technology in tables that use colspan or rowspan attributes in table header or data cells.
The first row of each table should include column headings. Typically, these column headings are inserted in <th> tags, although <td> tags can also be used. These tags at the top of each column should include the following attribute:
scope="col"By doing this simple step, the text in that cell becomes associated with every cell in that column. Unlike using other approaches (notably id and headers attributes) there is no need to include special attributes in each cell of the table. Similarly, the first column of every table should include information identifying information about each row in the table. Each of the cells in that first column are created by either <th> or <td> tags. Include the following attribute in these cells:
scope="row"By simply adding this attribute, the text in that cell becomes associated with every cell in that row. While this technique dramatically improves the usability of a web page, using the scope attribute does not appear to interfere in any way with browsers that do not support the attribute.
The following simple table summarizes: the work schedule of three employees and demonstrates these principles.
<table>
<tr>
<th> </th>
<th scope="col">Spring</th>
<th scope="col">Summer</th>
<th scope="col">Autumn</th>
<th scope="col">Winter</th>
</tr>
<tr>
<td scope="row">Betty</td>
<td>9-5</td>
<td>10-6</td>
<td>8-4</td>
<td>7-3</td>
</tr>
<tr>
<td scope="row">Wilma</td>
<td>10-6</td>
<td>10-6</td>
<td>9-5</td>
<td>9-5</td>
</tr>
<tr>
<td scope="row">Fred</td>
<td>10-6</td>
<td>10-6</td>
<td>10-6</td>
<td>10-6</td>
</tr>
</table>This table would be displayed as follows:
| Spring | Summer | Autumn | Winter | |
|---|---|---|---|---|
| Betty | 9-5 | 10-6 | 8-4 | 7-3 |
| Wilma | 10-6 | 10-6 | 9-5 | 9-5 |
| Fred | 10-6 | 10-6 | 10-6 | 10-6 |
The efficiency of using the scope attribute becomes more apparent in much larger tables. For instance, if an agency used a table with 20 rows and 20 columns, there would be 400 data cells in the table. To make this table comply with this provision without using the scope attribute would require special coding in all 400 data cells, plus the 40 header and row cells. By contrast, using the scope attribute would only require special attributes in the 40 header and row cells.
ID" and "Headers" Attributes in TablesUnlike using the scope attribute, using the id and headers attributes requires that every data cell in a table include special attributes for association. Although its usefulness for accessibility may have been diminished as browsers provide support for the scope attribute, the id and headers attributes are still very useful and provide a practical means of providing access in smaller tables.
The following table is much more complicated than the previous example and demonstrates the use of the id and headers attributes and then the scope attribute. Both methods provide a means of complying with the requirements for data tables in web pages. The table in this example includes the work schedules for two employees. Each employee has a morning and afternoon work schedule that varies depending on whether the employee is working in the winter or summer months. The "summer" and "winter" columns each span two columns labeled "morning" and "afternoon." Therefore, in each cell identifying the work schedule, the user needs to be told the employee' s name (Fred or Wilma), the season (Summer or Winter), and the shift (morning or afternoon).
<table>
<tr>
<th> </th>
<th colspan="2" id="winter">Winter</th>
<th colspan="2" id="summer">Summer</th>
</tr>
<tr>
<th> </th>
<th id="am1">Morning</th>
<th id="pm1">Afternoon</th>
<th id="am2">Morning</th>
<th id="pm2">Afternoon</th>
</tr>
<tr>
<td id="wilma">Wilma</td>
<td headers="wilma am1 winter">9-11</td>
<td headers="wilma pm1 winter">12-6</td>
<td headers="wilma am2 summer">7-11</td>
<td headers="wilma pm2 summer">12-3</td>
</tr>
<tr>
<td id="fred">Fred</td>
<td headers="fred am1 winter">10-11</td>
<td headers="fred pm1 winter">12-6</td>
<td headers="fred am2 summer">9-11</td>
<td headers="fred pm2 summer">12-5</td>
</tr>
</table> This table would be displayed as follows:
| Winter | Summer | |||
|---|---|---|---|---|
| Morning | Afternoon | Morning | Afternoon | |
| Wilma | 9-11 | 12-6 | 7-11 | 12-3 |
| Fred | 10-11 | 12-6 | 9-11 | 12-5 |
Coding each cell of this table with id and headers attributes is much more complicated than using the scope attribute shown below:
<table>
<tr>
<th> </th>
<th colspan="2" scope="col">Winter</th>
<th colspan="2" scope="col">Summer</th>
</tr>
<tr>
<th> </th>
<th scope="col">Morning</th>
<th scope="col">Afternoon</th>
<th scope="col">Morning</th>
<th scope="col">Afternoon</th>
</tr>
<tr>
<td scope="row">Wilma</td>
<td>9-11</td>
<td>12-6</td>
<td>7-11</td>
<td>12-3</td>
</tr>
<tr>
<td scope="row">Fred</td>
<td>10-11</td>
<td>12-6</td>
<td>9-11</td>
<td>12-5</td>
</tr>
</table> This table would be displayed as follows:
| Winter | Summer | |||
|---|---|---|---|---|
| Morning | Afternoon | Morning | Afternoon | |
| Wilma | 9-11 | 12-6 | 7-11 | 12-3 |
| Fred | 10-11 | 12-6 | 9-11 | 12-5 |
summary attribute an option?Although highly recommended by some web page designers as a way of summarizing the contents of a table, the summary attribute of the <table> tag is not sufficiently supported by major assistive technology manufacturers to warrant recommendation. Therefore, web developers who are interested in summarizing their tables should consider placing their descriptions either adjacent to their tables or in the body of the table, using such tags as the <caption> tag. In no event should web developers use summarizing tables as an alternative to making the contents of their tables compliant as described above.
Frames provide a means of visually dividing the computer screen into distinct areas that can be separately rewritten. Unfortunately, frames can also present difficulties for users with disabilities when those frames are not easily identifiable to assistive technology. For instance, a popular use of frames is to create "navigational bars" in a fixed position on the screen and have the content of the web site retrievable by activating one of those navigational buttons. The new content is displayed in another area of the screen. Because the navigational bar doesn' t change, it provides a stable "frame-of-reference" for users and makes navigation much easier. However, users with disabilities may become lost if the differences between the two frames are not clearly established.
The most obvious 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 titles like this at the top of the contents of each frame will satisfy these requirements. An additional measure that should be considered by agencies is to include meaningful text in the <frame> tag'
s title attribute. Although not currently supported by major manufacturers of assistive technology, the title attribute is part of the HTML 4.0 specification and was intended to let web developers include a description of the frame as a quote-enclosed string. Demonstrating the use of the title attribute requires a basic understanding of how frames are constructed. When frames are used in a web page, the first page that is loaded must include a <frameset> tag that encloses the basic layout of the frames on the page. Within the <frameset> tag, <frame> tags specify the name, initial contents, and appearance of each separate frame. Thus, the following example uses the title attribute to label one frame "Navigational Links Frame" and the second frame "Contents Frame."
<frameset cols="30%, 60%">
<frame src="navlinks.html" name="navlinks"
title="Navigational Links Frame">
<frame src="geninfo.html" name="contents_page"
title="Contents Frame">
</frame> While assistive technology does not yet widely support the title attribute, we recommend including this attribute in web pages using frames.
This provision is necessary because some individuals with photosensitive epilepsy can have a seizure triggered by displays that flicker, flash, or blink, particularly if the flash has a high intensity and is within certain frequency ranges. The 2 Hz limit was chosen to be consistent with proposed revisions to the ADA Accessibility Guidelines which, in turn, are being harmonized with the International Code Council (ICC)/ANSI A117 standard, Accessible and Usable Buildings and Facilities, ICC/ANSI A117.1-1998 which references a 2 Hz limit. An upper limit was identified at 55 Hz.
Flashing or flickering elements are usually added through technologies such as animated gifs, Java applets, or third-party plug-ins or applications. Java applets and third-party plug-ins can be identified by the presence of <applet> or <object> tags. Animated gifs are images that download in a single file (like ordinary image files), but have content that changes over short periods of time. Like other images, however, they are usually incorporated through the use of the <img> tag.
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.
Example: Disability.gov displays a text-only page on home page.
HTML source code:
<div ID="textonly">
<p>
<a HREF="../textonly/default.asp">Text Only</a>
</p>
</div> 
Example: Disability.gov displays a text-only page on home page.
Web page authors have a responsibility to provide script information in a fashion that can be read by assistive technology. When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used.
Web developers working with JavaScript frequently use so-called JavaScript URLs as an easy way to invoke JavaScript functions. Typically, this technique is used as part of <a> anchor links. For instance, the following link invokes a JavaScript function called myFunction:
<a href="javascript:myFunction();">Start myFunction</a> This technique does not cause accessibility problems for assistive technology. A more difficult problem occurs when developers use images inside of JavaScript URLs without providing meaningful information about the image or the effect of the anchor link. For instance, the following link also invokes the JavaScript function myFunction, but requires the user to click on an image instead of the text "Start myFunction":
<a href="javascript:myFunction();"><img src="myFunction.gif"></a>This type of link, as written, presents tremendous accessibility problems, but those problems can easily be remedied. The <img> tag, of course, supports the alt attribute that can also be used to describe the image and the effect of clicking on the link. Thus, the following revision remedies the accessibility problems created in the previous example:
<a href="javascript:myFunction();">
<img src="myFunction.gif" alt="picture link for starting myFunction">
</a> Another technique advocated by some developers is to use the title attribute of the <a> tag. For instance, the following example includes a meaningful description in a title attribute:
<a title="this link starts myFunction" href="javascript:myFunction();">
<img src="myFunction.gif">
</a>This tag is supported by some but not all assistive technologies. Therefore, while it is part of the HTML 4.0 specifications, authors should use the alt tag in the enclosed image.
Finally, the browser'
s status line (at the bottom of the screen) typically displays the URL of any links that the mouse is currently pointing towards. For instance, if clicking on an anchor link will send the user to http://www.usdoj.gov, that URL will be displayed in the status line if the user'
s mouse lingers on top of the anchor link. In the case of JavaScript URLs, the status line can become filled with meaningless snips of script. To prevent this effect, some web developers use special "event handlers" such as onmouseover and onmouseout to overwrite the contents of the status line with a custom message. For instance, the following link will replace the content in the status line with a custom message "Nice Choice."
<a href="javascript:myFcn();" onmouseover="status='Nice Choice';
return true;" onmouseout="status='';">
<img src="pix.gif">
</a>This text rewritten into the status line is difficult or impossible to detect with a screen reader. Although rewriting the status line did not interfere with the accessibility or inaccessibility of the JavaScript URL, web developers should ensure that all important information conveyed in the status line also be provided through the alt attribute, as described above.
JavaScript uses so-called "event handlers" as a trigger for certain actions or functions to occur. For instance, a web developer may embed a JavaScript function in a web page that automatically checks the content of a form for completeness or accuracy. An event handler associated with a "submit" button can be used to trigger the function before the form is actually submitted to the server for processing. The advantage for the government agency is that it saves government resources by not requiring the government' s server to do the initial checking. The advantage for the computer user is that feedback about errors is almost instantaneous because the user is told about the error before the information is even submitted over the Internet.
Web developers must exercise some caution when deciding which event handlers to use in their web pages, because different screen readers provide different degrees of support for different event handlers. The following includes recommendations for using many of the more popular event handlers:
onClickonClick event handler is triggered when the user clicks once on a particular item. It is commonly used on links and button elements and, used in connection with these elements, it works well with screen readers. If clicking on the element associated with the onClick event handler triggers a function or performs some other action, developers should ensure that the context makes that fact clear to all users. Do not use the onClick event handlers for form elements that include several options (e.g. select lists, radio buttons, checkboxes) unless absolutely necessary.onDblClickonDblClick event handler is set off when the user clicks twice rapidly on the same element. In addition to the accessibility problems it creates, it is very confusing to users and should be avoided.onMouseDown and onMouseUponMouseDown and onMouseUp event handlers each handle the two halves of clicking a mouse while over an element – the process of (a) clicking down on the mouse button and (b) then releasing the mouse button. Like onDblClick, this tag should be used sparingly, if at all, by web developers because it is quite confusing. In most cases, developers should opt for the onClick event handler instead of onMouseDown.onMouseOver and onMouseOutonLoad and onUnloadonChange<select> tag. Surprisingly, it presents tremendous accessibility problems for many commonly used screen readers and should be avoided. Instead, web developers should use the onClick event handler (associated with a link or button that is adjacent to a <select> tag) to accomplish the same functions.onBlur and onFocusWhile most web browsers can easily read HTML and display it to the user, several private companies have developed proprietary file formats for transmitting and displaying special content, such as multimedia or very precisely defined documents. Because these file formats are proprietary, web browsers cannot ordinarily display them. To make it possible for these files to be viewed by web browsers, add-on programs or "plug-ins" can be downloaded and installed on the user' s computer that will make it possible for their web browsers to display or play the content of the files. This provision requires that web pages that provide content such as Real Audio or PDF (Adobe Acrobat' s Portable Document Format) files also provide a link to a plug-in that will meet the software provisions. It is very common for a web page to provide links to needed plug-ins. For example, web pages containing Real Audio almost always have a link to a source for the necessary player. This provision places a responsibility on the web page author to know that a compliant application exists, before requiring a plug-in.
Plug-ins can usually be detected by examining a page'
s HTML for the presence of an <object> tag. Some plug-in manufacturers, however, may require the use of proprietary tags. Like plug-ins, applets can also be identified by the presence of an <object> tag in the HTML source for a web page. Also, an <applet> tag may signal the inclusion of an applet in a web page.
Currently, the interaction between form controls and screen readers can be unpredictable, depending upon the design of the page containing these controls. HTML forms pose accessibility problems when web developers separate a form element from its associated label or title. For instance, if an input box is intended for receiving a user' s last name, the web developer must be careful that the words "last name" (or some similar text) appear near that input box or are somehow associated with it. Although this may seem like an obvious requirement, it is extremely easy to violate because the visual proximity of a form element and its title offers no guarantee that a screen reader will associate the two or that this association will be obvious to a user of assistive technology.
The following form demonstrates these problems. Visually, this form is part of a table and each field is carefully placed in table cells adjacent to their corresponding labels (n.b. formatting forms with tables are by no means the only situation presenting the accessibility problems inherent in forms; tables merely illustrate the problem most clearly).
While the relationship between the titles "First Name" or "Last Name" and their respective input boxes may be obvious from visual inspection, the relationship is not obvious to a screen reader. Instead, a screen reader may simply announce "input box" when encountering each input box. The reason for these difficulties is revealed from inspecting the HTML source for this table. The following code is a simplified version of this table.
<form>
<table>
<tr>
<td><b>FIRST NAME:</b></td>
<td><input type="text" name="firstname"></td>
</tr>
<tr>
<td><b>LAST NAME:</b></td>
<td><input type="text" name="lastname"></td>
</tr>
</table>
<p></p>
<input type="submit" value="submit">
</form>The two pairs of form elements are indicated in bold above. The problem created by laying out form elements inside of this table is now clear – the form elements are separated from their labels by the formatting instructions for the table.
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.
Experience has shown that explicit labeling works extremely well with all popular assistive technology and is recommended in all but the very simplest of tables. We recommend that all agencies ensure that their web developers are familiar with these important concepts. Using "explicit" labels involves two distinct steps:
<label> tag and associated for attribute to tag labels. In other words, identify the exact words that you want to use as the label for the form element and enclose those words in a <label> tag. Use the form attribute to uniquely identify that element.Use the id attribute in the associated form element. Every form element supports the id attribute. By setting this attribute to the identifier used in the form attribute of the associated <label> tag, you "tie" that form element to its associated label. For instance, we have rewritten the HTML code for our simple form-inside-a-table to include explicit labels below. The new HTML for the explicit labels is indicated in bold:
<form>
<table>
<tr>
<td><b><label for="first"> first name:</label></b></td>
<td><input type="text" name="firstname" id="first"></td>
</tr>
<tr>
<td><b><label for="last"> last name:</label></b></td>
<td><input type="text" name="lastname" id="last"></td>
</tr>
</table>
<p></p>
<input type="submit" value="submit">
</form>In a nutshell, that' s all there is to making HTML form elements accessible to assistive technology. Experience has shown that this technique works extremely well in much more complicated and convoluted forms and it should work well in all agency HTML forms.
In "implicit" labels, the form element and its associated label are contained within an opening <label> tag and a closing </label> tag. For instance, in the table above, an implicit label to associate the words "First Name" with its associated input cell, we could use an implicit label as follows:
<label>
<tr>
<td><b>first name:</b></td>
<td><input type="text" name="firstname"></td>
</tr>
</label>Experience has shown that implicit labeling should be avoided for two reasons. First, implicit labeling is not reliably supported by many screen readers and, in particular, does not work well if explicit labels are simultaneously used anywhere on the same web page. Often, the output can be wildly inaccurate and confusing. Second, if any text separates a label from its associated form element, an implicit label becomes impractical and confusing because the label itself is no longer easily identified with the form element.
This provision provides a method to facilitate the easy tracking of page content that provides users of assistive technology the option to skip repetitive navigation links. 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 nondisabled 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. In order to alleviate this problem, the section 508 rule requires that when repetitive navigational links are used, there must be a mechanism for users to skip repetitive navigational links.
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. For this reason, 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.
Example: Thrift Savings Plan
