| En Español |
Appendix II-A
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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.
Using the "ID"
and "Headers" Attributes in Tables
Unlike 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 |
Is the summary attribute an
option?
Although highly recommended by some webpage 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.
(i) Frames shall be titled with text that facilitates frame identification and navigation.
Why is this provision necessary?
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 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.
What is the best method for identifying
frames?
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.
Example: ADA Technical Assistance Program
- The use of frames with “No Frames Link”
www.adata.org
(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
Why is this provision necessary?
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.
How can flashing or flickering elements be
identified?
Flashing or flickering elements are usually added through
technologies such as animated gif's, 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 gif's 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.
(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of these standards, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
What must a text-only page contain to comply
with this provision?
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>
Link: http://www.disability.gov/
(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.
What accessibility problems can scripts
cause?
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.
How can web developers comply with this
provision?
Web developers working with JavaScript frequently use
so-called JavaScript URL's 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 URL's without providing meaningful information about the image or the effect of the anchor link. For instance, the following link alsoinvokes 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 URL's, 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 table includes recommendations for using many of the more popular event handlers:
(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).
Why is this provision necessary?
While
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.
How can plug-ins and applets be
detected?
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 also signal the inclusion of an applet in
a web page.
(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.
Why do electronic forms present difficulties
to screen readers?
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>
<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.
How can developers provide accessible HTML
forms?
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.
“Explicit Labels" Work Well
Experience has shown that explicit labeling works extremely well
with all popular assistive technology and are 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:
<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>
<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.
Avoid Using "Implicit
Labels"
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.
(o) A method shall be provided that permits users to skip repetitive navigation links.
Why do navigational links present impediments
to screen readers and other types of assistive technologies?
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.
Example: USDA Target Center and DOL
websites use the Skip Repetitive Navigational Links.
http://www.usda.gov/oo/target.htm
(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
Why do timed responses present problems to web
users with disabilities?
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
www.tsp.gov
*** This page was originally from the Access Board Site. For more information, please visit Guide to the Section 508 Standards for Electronic and Information Technology
Last Updated: 6/14/04
