This category contains the 508 rules specified by the Accessibility Board (http://www.access-board.gov/sec508/508standards.htm).
For more details also suggest to look at a short course on accessibility at http://www.jimthatcher.com/webcourse1.htm, and a self-evaluation guide for accessibility at http://www.usdoj.gov/crt/508/web.htm.
Images included in this document do not have corresponding valid textual descriptions. A valid description is a string value of the ALT attribute that:
The image appears to have more than a decorative role (i.e., it is not a spacer).
The ALT attribute describes the associated image so that users without graphics-enabled browsers can still effectively navigate the page. The advent of hand-held, text-only browsers makes the use of the ALT descriptions more important now than ever.
For hidden links (normal A tags whose label is a spacer), it is important that the ALT attribute of the image exists and describes the destination of the link. (Hidden links is a technique you can use to fulfill the 508 rule 1194.22(o) stating "A method shall be provided that permits users to skip repetitive navigation links," and the WAI checkpoint 13.6.)
ALT descriptions are displayed before the associated image, which is helpful when image download and display takes several seconds.
Adding keywords to the ALT attribute can also improve the page listing in some search engine.
For images that play only a decorative role in the page (like spacers and bullets), it is recommended that you define an empty ALT (i.e. ALT="" ) so that speaking browsers do not confuse your users to say things like "*" or ">".
Add the ALT attribute to the IMG tag. Remember the following points:
Images in this document that seem to serve decorative purposes only (spacers) do not have corresponding valid textual descriptions. A valid textual description is a blank or empty string for the ALT attribute value.
The ALT attribute describes the associated image so that users without graphics-enabled browsers can still effectively navigate the page. Images that have only a decorative role do not need to have a textual description since users unable to see the image will not care about it.
In addition, speaking browsers or screen readers will not bother their users if the ALT text is a blank or empty string. A blank string is a string made up of one or more spaces, such as " ". An empty string is a string with no spaces at all, such as "".
The ALT attribute should be defined even if the value is a blank or empty string. Otherwise a screen reader or speaking browser might insert the image filename, for example, disturbing the user while listening to the page.
Add the ALT attribute to the IMG tag.
For a spacer, the ALT attribute value should be a blank (" ") or empty ("") string, but it should exist anyway. The same applies for images used as bullets.
The image appears to have more than a decorative role (i.e., it is not a spacer). It should have an equivalent textual description.
The ALT attribute describes the associated image so that users without graphics-enabled browsers can still effectively navigate the page.
The description should convey the same information as the image and it should explain the role the image plays on the page - why it is there, what it represents, how it presents the information.
If the image is used within a hidden link (that is, a normal A tag with a spacer as label), then its ALT attribute should describe the link destination. The ALT content is all that non-graphical browsers show for a hidden link. (Hidden links is a technique that can be used to fulfill the 508 rule 1194.22(o), which states "A method shall be provided that permits users to skip repetitive navigation links," and the WAI checkpoint 13.6.)
Notice that adding a good alternative description to images is very important today as many users, for one reason or the other, are not able to take advantage of graphics. They include users of cellular phones, PDAs, or browsers installed in cars.
Check to make sure the current ALT description conveys the meaning of the image.
The description should explain the role the image plays on the page: why it is there, what it represents, how it presents the information. Imagine hearing the description over the phone.
If the image is used as the content of a link and you provide link text too, use a space as the ALT attribute value of the IMG element. In such a case, link text should be the alternative description for the image.
If the image is used as a hidden link, then its ALT attribute should describe the link destination.
If the image has only decorative purposes (such as images used for bullets or spacers), the ALT string should be a empty string ("") or a blank one (" ").
Image has a LONGDESC attribute that is not valid for one of the following reasons:
The ALT attribute cannot be used to provide a full-length description of the content of an image. Think of a diagram, a histogram, a chart, or a product picture in an online catalogue. To describe its content, you need more flexibility.
The LONGDESC attribute can be used to provide a long description of the associated image. By including the attribute LONGDESC="any_HTML_file" in your IMG tag, you can link the image to the HTML file containing a formatted description of the image. The long description (unlike the ALT attribute) can contain HTML code, with links to other resources, formatting instructions, and more.
However, since not many browsers at the moment support the LONGDESC attribute, you may also want to place a so-called D-link near the image. A D-link is a normal textual link with a label "D" pointing to an HTML page providing a full image description. Example:
<IMG src="chart.gif" alt="chart of beverages distribution"
longdesc="chart.html"><A href="chart.html">D</A>
Placing a rich textual description such as a caption close to the image is another viable solution. In such a case, you will not need the LONGDESC attribute or the D-link.
Adding a good alternative description to images is very important today because many users can't take advantage of graphics. They include users of cellular phones, PDAs, and browsers installed in cars.
Make sure the link specified by the LONGDESC attribute is working.
Since not many browsers at the moment support the LONGDESC attribute, you may also want to place a so-called D-link near the image. A D-link is a normal textual link with label "D" pointing to an HTML page providing a full image description. Example:
<IMG src="chart.gif" alt="chart of beverages distribution"
longdesc="chart.html"><A href="chart.html">D</A>
Placing a rich textual description such as a caption close to the image is another viable solution. In such a case, you will not need the LONGDESC attribute or the D-link.
Image has a LONGDESC attribute even though the image appears to be decorative only.
Decorative images should not have any long descriptions.
The LONGDESC attribute can be used to provide a long description of the associated image when the description would not fit in the ALT attribute. This may be needed, for example, when the image represents a chart or a diagram, which typically need long explanations.
However, for images used only for decorative purposes, a long description is unnecessary, and people using browsers that take advantage of that feature will find it distracting.
Remove the LONGDESC attribute from the IMG tag.
Image does not have a LONGDESC attribute that points to an HTML file providing a detailed description of the image.
The ALT attribute cannot be used to provide a full-length description of the content of an image. Think of a diagram, a histogram, a chart, or a product picture in an online catalogue. To describe its content, you need more flexibility.
The LONGDESC attribute can be used to provide a long description of the associated image. By including the attribute LONGDESC="any_HTML_file" in your IMG tag, you can link the image to the HTML file containing a formatted description of the image. The long description (unlike the ALT attribute) can contain HTML code, with links to other resources, formatting instructions, and more.
However, since not many browsers at the moment support the LONGDESC attribute, you may also want to place a so-called D-link near the image. A D-link is a normal textual link with a label "D" pointing to an HTML page providing a full image description. Example:
<IMG src="chart.gif" alt="chart of beverages distribution"
longdesc="chart.html"><A href="chart.html">D</A>
Placing a rich textual description such as a caption close to the image is another viable solution. In such a case, you will not need the LONGDESC attribute or the D-link.
Adding a good alternative description to images is very important today because many users can't take advantage of graphics. They include users of cellular phones, PDAs, and browsers installed in cars.
Make sure the image presents information that is not included in the page or in the text equivalent of the image (that is, in its ALT attribute).
If describing the image will add information not present in the text of the page, then you need to provide a description of the image. The amount of information in the image and the context in which it will be used will determine how detailed the description should be.
However, since not many browsers at the moment support the LONGDESC attribute, you may also want to place a so-called D-link near the image. A D-link is a normal textual link with a label "D" pointing to an HTML page providing a full image description. Example:
<IMG src="chart.gif" alt="chart of beverages distribution"
longdesc="chart.html"><A href="chart.html">D</A>
Placing a rich textual description such as a caption close to the image is another viable solution. In such a case, you will not need the LONGDESC attribute or the D-link.
Image used as a button in the form does not have a valid textual description.
Image does not have a LONGDESC attribute linking it to an HTML file that provides a detailed description that would not fit in the ALT attribute. A valid description is a string value of the ALT attribute that is not any of the following:
The ALT attribute describes the associated image so that users without graphics-enabled browsers can still effectively navigate the page. The advent of hand-held, text-only browsers makes the use of ALT descriptions more important now than ever.
If the button image does not have a textual description, users of non-graphical browsers will have no idea what clicking on that button will do.
Beware of another possible problem:
When the mouse is used to click on the image, the form and the click coordinates are submitted to the server.
If the server takes different actions depending on the location clicked, users of non-graphical browsers will be disadvantaged. For this reason, you should consider alternate approaches such as the following:
Add the ALT attribute to the INPUT element while keeping the following in mind:
Beware that when the mouse is used to click on the image, the form and the click coordinates are submitted to the server. If the server takes different actions depending on the location clicked, users of non-graphical browsers will be disadvantaged. For this reason, you should consider alternate approaches such as the following:
Image used as a button in the form has a valid description.
It should have an equivalent textual description.
The ALT attribute describes the associated image so that users without graphics-enabled browsers can still effectively navigate the page. The advent of hand-held, text-only browsers makes the use of the ALT descriptions more important now than ever.
If the button image does not have an equivalent textual description, users of non-graphical browsers will have no idea what clicking that button will do.
Beware of another possible problem. When the mouse is used to click on the image, the form and the click coordinates are submitted to the server. If the server takes different actions depending on the location clicked, users of non-graphical browsers will be disadvantaged. For this reason, you should consider alternate approaches such as the following:
Test the content of the ALT attribute of the INPUT element.
Remember that the description should explain the effect of
clicking on the button.
Beware that when the mouse is used to click on the image, the form and the click coordinates are submitted to the server. If the server takes different actions depending on the location clicked, users of non-graphical browsers will be disadvantaged. For this reason, you should consider alternate approaches such as the following:
The frame's LONGDESC attribute is invalid because of one of the following reasons:
The LONGDESC attribute can be used to provide a long description of the associated FRAME tag when the description would not fit in the TITLE attribute. This would be needed, for example, if the frame contained only an image with no text around it.
The LONGDESC attribute describes the frame content so that users without graphics-enabled browsers can still effectively understand what is being presented in the page. The advent of hand-held, text-only browsers makes the use of textual descriptions more important now than ever.
The W3C/WAI discourages putting an image directly in a frame (to learn why, see http:www.w3.org/TR/REC-html40/present/frames.html#h-16.4.2) and suggests instead having the frame point to a separate HTML file that includes the image and some explanatory text.
Ensure that the link specified by the LONGDESC attribute is working.
Note that the W3C/WAI discourages using the LONGDESC attribute for framed images, and suggests instead having the frame point to a separate HTML file that includes the image and some explanatory text.
SCRIPT element does not have an associated valid NOSCRIPT:
Note that the 508 standard
does not
require that all SCRIPTS be followed by corresponding
NOSCRIPTS (though it is a suggested technique in WAI WCAG
1.0). The 508 standard requires that when pages use
scripting languages to display content or to create
interface elements, the information provided by the script
should be identified with functional text that can be read
by assistive technology.
There are two kinds of scripts that require special care
and using the NOSCRIPT tag may help:
One way to provide a text equivalent to a SCRIPT element is with NOSCRIPT. The content of this element is rendered when scripts are not enabled.
The NOSCRIPT element allows authors to provide alternate content when a script is not executed. The content of a NOSCRIPT element should only be rendered by a script-aware user agent in the following cases:
Users of screen readers and speaking browsers would not be able to take advantage of scripts that affect the graphical interface of a web page.
Users not using a mouse or joystick would not be able to take advantage of scripts that open windows, dialogs, or menus.
Note that there are many other cases where scripts cannot be run by browsers, and there are going to be more and more of these cases in the future. They include:
Check that the information provided by the script can be also provided by text that can be read by assistive technology.
The easiest way to check if a script is accessible is to
try to view the page with a browser where scripts and image
loading are temporarily disabled (consult the browser's
documentation to learn how to disable scripts and image
loading).
Another approach is to use the page without the mouse (by
tabbing through elements and using only the keyboard). This
gives you an idea of the role actual played by the script
in the interaction.
If not, consider adding a NOSCRIPT element to the SCRIPT. It can contain any HTML tag. Its content should let people that do not execute the script achieve the same effects as those that do. In particular, they should be able to access the same content and same interaction opportunities, including links.
Script included in this document has a valid NOSCRIPT element whose content should be equivalent to the script.
A NOSCRIPT is valid if the following conditions apply: it exists, it is close to the SCRIPT it refers to, and it is not empty.
One way to provide a text equivalent to a SCRIPT element is with NOSCRIPT. The content of this element is rendered when scripts are not enabled.
The NOSCRIPT element allows authors to provide alternate content when a script is not executed. The content of a NOSCRIPT element should only be rendered by a script-aware user agent in the following cases:
Users of screen readers and speaking browsers would not be able to take advantage of scripts that affect the graphical interface of a web page.
Users not using a mouse or joystick would not be able to take advantage of scripts that open windows, dialogs, and menus.
Note that there are also many other cases where scripts cannot be run by browsers, and there are going to be more and more cases in the future. They include:
Make sure the content of the current NOSCRIPT conveys the same meaning of the associated SCRIPT.
The content of NOSCRIPT should let people that do not execute the script achieve the same effects as those that do. In particular, they should be able to access the same content and same interaction opportunities, including links.
NOSCRIPT can contain any HTML tag.
The image map included in this document does not have AREAs elements with valid textual descriptions. A valid description is a string value of the ALT attribute that is not any the following:
ALT attributes are the means to provide text equivalents for image maps. Doing so is important since image maps convey visual information crucial for navigation.
The ALT attribute should describe the associated area of the image so that users without graphics-enabled browsers can still effectively navigate the page. Without ALT descriptions, such users would not be able to navigate through the image map.
Each AREA element of the image map should have its own ALT attribute. Example (taken and revised from a tutorial at http://www.jimthatcher.com/webcourse2.htm):
<IMG src="map.gif" alt="navigation" usemap="#navigation"> <MAP name="navigation"> <AREA coords="1,1,40,100" alt="home" href="../index.html"> <AREA coords="1,100,40,180" alt="products" href="products.html"> </MAP>
As with other links, the link text should make sense when read out of context. Good link text should not be overly general. Do not use "click here." Not only is this phrase device-dependent (it implies a pointing device), but it says nothing about what is to be found if the link is clicked. Instead of "click here," link text should indicate the nature of the link target, as in "more information about sea lions" or "text-only version of this page".
The advent of hand-held, text-only browsers makes the use of the ALT descriptions more important now than ever. Consider that many users by choice or necessity use text-only browsers with screen readers or speaking browsers. They include visually impaired persons, people using the web over a phone, and people using a speaking browser in the car.
Until user agents are able to render text equivalents for client-side image map links, you can make your page accessible to users that cannot see the graphics by providing redundant textual links for each active region of a client-side image map. By providing the ALT description for AREA elements, however, your page is already compliant with respect to these new browsers.
Add the ALT attribute to the AREA tag while keeping the following points in mind:
The image map included in this document has AREAs elements
with valid textual descriptions.
These descriptions should be equivalent to the image map.
ALT attributes are the means to provide text equivalents for image maps. Doing so is important since image maps convey visual information crucial for navigation.
The ALT attribute should describe the associated area of the image so that users without graphics-enabled browsers can still effectively navigate the page. Without equivalent ALT descriptions, such users would not be able to navigate through the image map.
As with other links, the link text should make sense when read out of context. Good link text should not be overly general. Do not use "click here." Not only is this phrase device-dependent (it implies a pointing device), but it says nothing about what is to be found if the link is click. Instead of "click here", link text should indicate the nature of the link target, as in "more information about sea lions" or "text-only version of this page".
The advent of hand-held, text-only browsers makes the use of the ALT descriptions more important now than ever. Consider that many users by choice or necessity use text-only browsers with screen readers or speaking browsers. They include visually impaired persons, people using the web over a phone, and people using a speaking browser in the car.
Until user agents can render text equivalents for client-side image map links, you can make your page accessible to users that cannot see the graphics by providing redundant textual links for each active region of a client-side image map. By providing the ALT description for AREA elements, however, your page is already compliant with respect to these new browsers.
Test the ALT attribute of the AREA tag while keeping the following points in mind:
The page contains colors, so make sure the information conveyed with the page does not rely on those colors.
There are many situations where a person cannot see colors. They include:
Colors on a page should be used only as decorative or graphic-enhancing devices. They should not be used to convey information.
Make sure the page can be understood and navigated even if users do not have the ability to identify specific colors or differentiate between colors.
Here are easy ways to test the page:
The page uses some colors; there might be cases where the contrast between foreground and background colors is not sufficient to differentiate them.
There are many situations where a bad choice of colors by the designer hinders perception and comprehension of some information or image on a page. They include:
Make sure colors and colored items on the page can be clearly differentiated in all the possible contexts in which users may be viewing the page. Make sure the contrast between foreground and background items is conveyed by other means than color, such as different font styles, font sizes, or font faces.
Here are easy ways to test the page:
The page requires the use of Cascading Style Sheets (CSS). Make sure the page can be understood and navigated without applying style specifications.
Cascading Style Sheets (CSS) is a great technology for separating content and its structure from presentation. Usually when content is organized logically, it will be rendered in a meaningful order when style sheets are turned off or not supported. However, there may be situations where CSS gets in the way, limiting accessibility to a web page.
For example, old browsers do not support CSS, and thus page authors should not rely on styles to convey information or enable navigation. Also, user-defined style information (such as font size, font color) should be unaffected by styles specified in the page.
Make sure the document can be read without style sheets.
The page includes a server-side image map. Verify that each active region of the image map has a redundant textual link.
Server-side image maps pose big accessibility problems, including:
For these reasons, the use of server-side image maps is highly discouraged. The only exception is for active regions whose shape are so irregular that client-side image maps cannot support them.
Make sure each active region of the image map is duplicated as a redundant link in the page. You must inspect the implementation of the image map on the server to determine the URLs that are activated when the user clicks on any of the active regions.
The page includes a server-side image map. Verify that the image map can be replaced by a more accessible client-side image map.
Server-side image maps pose big accessibility problems, including:
For these reasons, the use of server-side image maps is highly discouraged. The only exception is for active regions whose shape are so irregular that client-side image maps cannot support them.
You can recognize a server-side image map with a browser by pointing the mouse at the image. Mouse coordinates are displayed by the browser as you move the mouse over the image.
Determine whether the server-side image map is really needed. The only reason to use one is if you need to define active regions that cannot be defined with available shapes. If you must use one, you should at least provide alternative ways such as textual links to reach the same destination pages. (You must inspect the implementation of the image map on the server to find out how active regions are defined.)
The page includes a table that does not have specific cells marked as headers (i.e., with TH tags). If the table is used to present data, add headers to it.
Tables can be used to present data such as a bus schedule, a comparison of regional sales figures, or a listing of employee contact information. Cells in data tables like these are related to each other and usually must be perceived as a group. Tables can also be used to lay out images and text on a page. Each cell in a layout table like this is normally independent and can be viewed on its own.
Data tables are used to convey information in a bidirectional medium, which often is not available for certain users. Consider the following examples:
In all these cases, the user has to mentally remember the context of the cell (which row and column does it refer to?). This requirement may be too strong, for example, when the table is large, when the user is under stress, or is impatient to find the needed information.
Consider also that in these situations, users might not be able to move directly from one cell of the table to any other. They are constrained to move sequentially, from one cell to its neighbors only (within the same row, for example).
Layout tables, on the other hand, are not used to convey information and therefore they do not need to be accessible. Note however that W3C suggests using styles to lay out the content of a page. For more information, see http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-alignment.
Note also that layout tables are linearized by non-graphical browsers. In other words, the content of their cells are shown in the sequence they appear in the HTML file. This means that if the cells include buttons, they may be shown in a sequence that is far from being usable. For a detailed discussion, see http://www.jimthatcher.com/webcourse4.htm.
If the table presents data, make sure that each row and column has appropriate headers.
The simplest way to accomplish this is by defining a table row of cells marked with the TH tag and having the first cell of each other row marked with the TH tag again.
In addition:
Alternatively, the TH tag may have a SCOPE='col' or SCOPE='row' attribute, meaning that the header refers to the entire column or row, respectively.
It might be a good idea to use the ABBR attribute in the TH tag to provide a more concise description of the header to be repeated over and over by specialized browsers.
The page includes a table that has TH tags without ID or SCOPE attributes. If the table is used to present data, provide header information.
Tables can be used to present data such as a bus schedule, a comparison of regional sales figures, or a listing of employee contact information. Cells in data tables like these are related to each other and usually must be perceived as a group. Tables can also be used to lay out images and text on a page. Each cell in a layout table like this is normally independent and can be viewed on its own.
Data tables are used to convey information in a bidirectional medium, which often is not available for certain users. Consider the following examples:
In all these cases, the user has to mentally remember the context of the cell (which row and column does it refer to?). This requirement may be too strong, for example, when the table is large, when the user is under stress, or is impatient to find the needed information.
Consider also that in these situations, users might not be able to move directly from one cell of the table to any other. They are constrained to move sequentially, from one cell to its neighbors only (within the same row, for example).
Layout tables, on the other hand, are not used to convey information and therefore they do not need to be accessible. Note however that W3C suggests using styles to lay out the content of a page. For more information, see http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-alignment.
If the table is used to present data, make sure that each row and column has appropriate headers defined by TH tags.
In addition:
Alternatively, the TH tag may have a SCOPE='col' or SCOPE='row' attribute, meaning that the header refers to the entire column or row, respectively.
It might be a good idea to use the ABBR attribute in the TH tag to provide a more concise description of the header to be repeated over and over by specialized browsers.
The page includes a PRE tag with pre-formatted tabular data. If the PRE tag is used to present data, convert it to a TABLE tag.
Data tables are used to convey information in a bidirectional medium, which often is not available for certain users. Consider the following examples:
In all these cases, the user has to mentally remember the context of the cell (which row and column does it refer to?). This requirement may be too strong, for example, when the table is large, when the user is under stress, or is impatient to find the needed information.
Consider also that in these situations, users might not be able to move directly from one cell of the table to any other. They are constrained to move sequentially, from one cell to its neighbors only (within the same row, for example).
If you're using the PRE tag to arrange and present data in a tabular format, format the data in a table using the TABLE, TR, TH, TD tags with appropriate attributes (ID, HEADERS, SCOPE).
In addition:
Alternatively, the TH tag may have a SCOPE='col' or SCOPE='row' attribute, meaning that the header refers to the entire column or row, respectively.
It might be a good idea to use the ABBR attribute in the TH tag to provide a more concise description of the header to be repeated over and over by specialized browsers.
The page includes a TABLE tag with a TH tag and does not have any THEAD, TFOOT, TBODY elements. If the table is used to show data and if it includes multiple levels of row and column headers, then consider adopting THEAD, TFOOT, TBODY to mark up such levels.
Data tables are used to convey information in a bidirectional medium, which often is not available for certain users. Consider the following examples:
In all these cases, the user has to mentally remember the context of the cell (which row and column does it refer to?). This requirement may be too strong, for example, when the table is large, when the user is under stress, or is impatient to find the needed information.
Consider also that in these situations, users might not be able to move directly from one cell of the table to any other. They are constrained to move sequentially, from one cell to its neighbors only (within the same row, for example).
If the table is structured in different sections, each with its own row or column headers, then this structure should be clearly marked up so that specialized browsers can take advantage of it and articulate it (perhaps by repeating the appropriate headings when moving to a cell).
If you're using the table to present data and the data is organized in different sections requiring different headers, use the THEAD, TFOOT, TBODY tags (perhaps with COLGROUP and COL) to mark up the different sections.
The FRAME tag defined in the document does not have a valid TITLE attribute.
A TITLE attribute of a FRAME tag is valid if the following conditions exist: it exists, it is not an empty string (""), and it is nor a blank string (" ").
Frames are good for implementing complex navigational structures. However, if not implemented correctly they may become an obstacle for many users. Make sure your framed page can be accessed by any user using any possible technology in any possible context.
A general user interface design guideline is "to provide context and orientation information to help users understand complex pages or elements."
For frames, this means that the TITLE attribute should be defined because its value is the only thing non-graphical browsers show. In fact, each frame will be shown independently for the other ones, making it hard for the user to figure out their relationship. Titles like, "content area" or "navigationals" are much more informative than "left" or "top-frame".
Providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive or visual disabilities to interpret.
Cognitive disabilities do not refer only to people who are mentally challenged, but also people who work under specific adverse contexts, such as people using an e-ticketing service in an airport hall, a speaking browser by phone in a noisy environment, a PDA where a quick decision is required, or a browser during a meeting where changing the mental focus is difficult.
Similarly, visually disabled people also include people who forget their glasses at home, who use a poorly lit display in a dark environment, or who use a speaking browser or screen reader over a phone.
Define a valid TITLE attribute for the FRAME tag.
Title the frame to help frame identification and navigation by describing concisely the frame's content and role on the page.
Since the TITLE attribute is not widely supported, providing titles as normal text at the top of the contents of each frame is sufficient for the purposes of 508 rule 1194.22(i).
As an alternative, use the same string for both the TITLE and NAME attributes. For example, the Lynx textual browser uses only the NAME attribute.
A TITLE string value is valid if it meets the following requirements:
IFRAME tag defined in the document does not have a valid TITLE attribute.
A TITLE attribute of a IFRAME tag is valid if the following conditions apply: it exists; it is not an empty string (""), and it is not a blank string(" ").
Frames are good for implementing complex navigational structures. However, in many cases this added complexity may become an obstacle for many users. Make sure your framed page can be accessed by any user using any possible technology in any possible context.
A general user interface design guideline is "to provide context and orientation information to help users understand complex pages or elements."
Providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive or visual disabilities to interpret.
Cognitive disabilities does not refer only to people whom are mentally challenged, but also people who work under specific adverse contexts, such as people using an e-ticketing service in an airport hall, a speaking browser by phone in a noisy environment, a PDA where a quick decision is required, or a browser during a meeting where changing the mental focus is difficult.
Similarly, visually disabled people also include people who forget their glasses at home, who use a poorly lit display in a dark environment, or who use a speaking browser or screen reader over a phone.
Define a valid TITLE attribute for the IFRAME tag.
Title the frame to help frame identification and navigation by describing concisely the frame's content and role in the page.
Since the TITLE attribute is not widely supported, providing titles as normal text at the top of the contents of each frame is sufficient for the purposes of 508 rule 1194.22(i).
A TITLE string value is valid if it meets the following requirements:
The page contains programmatic objects that can make it inaccessible. If the page cannot be made accessible, there should be a text-only version of the page updated whenever the original page changes.
If a page cannot be made accessible, then an accessible, equivalent version of the page is needed. A text-only version of it would suffice. Text-only alternatives to inaccessible pages allow people with disabilities to have full access to all the information. The information or functionality on the alternative page must be equivalent to the information or functionality on the original page.
It is also important to update alternative pages when you update the original pages.
You should only resort to creating alternative pages when other solutions fail because these pages are generally updated less often than original pages. An out-of-date page may be as frustrating as an inaccessible one because the information presented on the original page is unavailable in both cases. Automatically generating alternative pages may lead to more frequent updates, but content developers must still be careful to ensure generated pages always make sense, and that users are able to navigate a site by following links on original pages, alternative pages, or both. Before resorting to an alternative page, reconsider the design of the original page. Making the original page accessible is likely to improve it for all users.
Determine whether the page satisfies all the 508 accessibility conditions. If some conditions are not satisfied, and the page cannot be changed to satisfy them, then you need an equivalent text-only version of this page.
Make sure such a page exists and that it is updated whenever a change is made to the original page.
The page contains a programmatic object such as a script, a plug-in, or an applet that may be used to change the content of the page or its navigation options - and perhaps reduce the page's accessibility.
Programmatic objects can change the presentation, content, and navigation options of a page. If some of these changes are not associated to text that can be read by assistive technology, then the page is not accessible. For example, using a script to show a menu of choices on a page without also providing the choices as textual links would make the page inaccessible.
A related concept is "device independence." As defined by W3C/WAI (see http://www.w3.org/TR/WAI-WEBCONTENT/#device-independent), it means that users must be able to interact with a website using the supported input and output devices of their choice according to their needs. Input devices may include pointing devices, keyboards, Braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and Braille devices.
Note that "device-independent support" does not mean that the browser must support every input or output device. It should offer redundant input and output mechanisms for those devices that are supported. For example, if a browser supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse.
Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device. For example, if a form control can only be activated with a mouse or other pointing device, someone using the page without sight, with voice input, or with a keyboard will not be able to use the form. The form is an example of device dependence, because its use would be possible only through a mouse.
Generally, pages that allow keyboard interaction are also accessible through speech input or a command-line interface.
Inaccessible programmatic objects may include:
Examine the programmatic object included on the page and see if it provides information or interaction options not available through other text on the page.
If the script cannot be made accessible, one solution is to include a NOSCRIPT tag with alternative and equivalent content and interaction (using a form).
Consider also transforming the client-side script into an equivalent server-side script. In this case, you must write it so that it produces accessible pages.
The page contains a programmatic object such as a plug-in or an applet that may require a specific plug-in for the browser to interpret the page content.
Check that the object is accessible or that the page contains a link to an equivalent object that is accessible. You should also check that the page contains a link to a resource where the plug-in can be downloaded.
Programmatic objects may change the presentation, content, or navigation options of a page. Programmatic objects include Java applets, Flash, ShockWave, RealAudio or RealVideo files. Each of these objects must be accessible. If this is not possible, then the page should contain links to other, accessible versions of the objects. When evaluating the accessibility of plug-ins, it may be useful to refer to the Access Board's section 508 rule as it applies to software, 36 C.F.R. 1194.21 (see http://www.access-board.gov/sec508/508standards.htm). In addition, if these objects require some specific plug-in for the browser, the page should provide the means for the user to get and install the plug-in.
In general, PDF documents can be created in several different ways and each method has separate implications for accessibility. Here are four methods:
Web developers should try to use the last two methods of creating PDF files and should avoid the first method entirely. You should also test the accessibility of your PDF documents using screen readers before posting them to web sites. Adobe's accessibility site includes the latest recommendations for making PDF files accessible (see http://access.adobe.com/). Finally, you should be careful that non-text content be accompanied by text descriptions in the PDF files. Developers that choose to publish web-based documents in PDF should simultaneously publish the same documents in another, more accessible format, such as HTML.
Make sure the object is accessible or that the page contains a link to an equivalent object that is accessible. Also make sure the page contains a link to a resource where the plug-in can be downloaded.
Applets included in this document do not have corresponding valid textual descriptions. A valid description is a string value of the ALT attribute that is not any of the following:
Here are cases where applets may not run:
You can use the ALT attribute to describe the behavior and content of the applet to these users.
Add the ALT attribute to the APPLET tag.
The ALT description should convey the same information as the applet, and it should explain the role the applet plays on the page: why it is there, what it represents, how it presents the information.
Applets included in this document should have corresponding equivalent textual descriptions in the ALT attribute and the applet's content.
Here are cases where applets may not run:
You can use the ALT attribute and the applet contents to describe the behavior and content of the applet to these users.
Check the applet's textual description in the ALT attribute value and the applet's content. It should convey the same information as the applet and explain the role the applet plays on the page: why it is there, what it represents, how it presents the information.
Applets included in this document do not have corresponding valid textual descriptions. A valid description is a string value for CONTENT that is not any of the following:
Here are cases where applets may not run:
Provide a text equivalent describing the behavior of the applet using the ALT attribute and the content in the APPLET tag. This enables the content to transform easily for those user agents that only support one of the two mechanisms (ALT or content).
Add a content to the APPLET tag.
The textual description should convey the same information as the applet, and it should explain the role the applet plays on the page: why it is there, what it represents, how it presents the information.
The page contains a FORM element whose components appear to be laid out by a table. The table may make the form unusable.
Using a table to lay out a form may make the form unusable. When the user accesses the page through a reading browser or through a device with a small screen such as a PDA or a cell phone, the table cells may be presented in a linear fashion (linearized). This may position the labels of text fields, checkboxes, or radio buttons in unintended places.
For a detailed discussion on the effect of layout tables on navigation, see http://www.jimthatcher.com/webcourse4.htm.
Another thing to consider is the tabbing order of the form elements. By pressing the TAB key on the keyboard, the user can move sequentially from one element to the next in the order defined on the HTML page. Sometimes, however, you might want to specify a different order. This can be achieved with the TABINDEX attribute of the INPUT, A, BUTTON, AREA, OBJECT, SELECT, and TEXTAREA tags inside a form.
You can also use the ACCESSKEY attribute to associate keyboard accelerators to activate the form elements.
Make sure the form elements and their associated labels are properly rendered by non-graphically enabled browsers. In particular, make sure the form is still usable after the table used to lay it out is linearized. A simple way to do this is to strip out the table tags. Another quick test is to run a piece of paper down the page and read your table line by line.
If the page contains a set of navigational links placed at standard positions (often across the top, bottom, or side of a page), then a textual link should be present to allow users of non-graphical browsers to skip those links and move to the page content.
Web designers often place a set of navigational links at a standard location such as across the top, bottom, or side of a page. If non-disabled visitors return to a web page or site and know that they want to view the content of that particular page instead of selecting a navigation link, they may simply look past the links and begin reading the desired text. 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 links before getting to the page content.
To address this problem, include a mechanism allowing users to skip repetitive navigational links.
If the page has a standard set of navigational links placed at a standard location, create a link that lets users skip those links. The easiest method is to use a normal text link such as "skip navigationals" that points to a named anchor on the same page.
A more effective method is to use a transparent GIF with an appropriate ALT attribute as the link. For example:
<A href="#content">
<IMG alt="skip to page content" src="spacer.gif" width="1"
height="1">
</A>
Users with graphical browsers won't see the link, but it would be seen and used by users with non-graphical browsers.
The page contains a link that can be followed only by browsers that support JavaScripts.
Links that activate scripts can only be followed by browsers capable of executing JavaScript. Not all browsers can do that. Examples include textual browsers like Lynx, browsers coupled with screen readers, and browsers for PDAs or cellular phones. A user with such a browser would not be able to navigate the page. Even if you provide other links or buttons to reach the destination, the user would still experience a broken link, thus increasing user frustration and confusion.
Replace the link that directly starts the script with other ways to start it, such as defining a button, separately defining the script (remember also the NOSCRIPT element), and binding an event like onKeyPress on the button to the script.
The page is automatically updated after a given time. You should remove this behavior.
Pages that are automatically updated may pose significant problems to people who are disabled or who use technology that hinders normal interaction patterns. For example, screen readers might not be working properly when the page updates, or people with physical disabilities might not be able to move quickly or accurately through the page content and navigation items. Also, people may face problems if for some reason they are slow in reading the page, if they use a very slow internet connection, or if they use a small screen that forces them to read more slowly. Until browsers allow users to turn off these automatically updating features, do not use auto-refresh.
Until browsers allow users to turn off automatically updating features, do not use auto-refresh. Try to achieve a similar effect by specifying caching properties and configure the web server appropriately. This would not affect the accessibility of the pages because the page would change only as a consequence of the user requesting a page from the server.
The page is automatically updated after a given time and a new page is automatically loaded after a given time. You should remove this behavior.
Pages that are automatically updated may pose significant problems to people who are disabled or who use technology that hinders normal interaction patterns. For example, screen readers might not be working properly when the page updates, or people with physical disabilities might not be able to move quickly or accurately through the page content and navigation items. Also, people may face problems if for some reason they are slow in reading the page, if they use a very slow internet connection, or if they use a small screen that forces them to read more slowly. Until browsers allow users to turn off these automatically updating features, do not use auto-refresh.
Until browsers allow users to turn off automatically updating features, do not use auto-refresh or auto-redirect. If auto-redirect is needed, then implement it using the redirection capabilities offered by the server. This will not affect accessibility of the pages because the page would change only as a consequence of the user requesting a page from the server. If this is not possible, then you should provide the users with the means to access and navigate the items present on the current page also in the new page that is loaded automatically. In this way, the user will still be able to access those items when the two pages switch.
The page contains a GIF image that may cause the screen to
flicker.
Make sure the page does not contain an animated GIF with a
refresh rate of between 2 to 55 frames per second.
A flickering or flashing screen may cause seizures in users with photosensitive epilepsy. As a result, content developers should avoid causing the screen to flicker.
Seizures can be triggered by a light flickering or flashing 2 to 55 times per second, with peak sensitivity at 20 flashes per second with quick changes from dark to light.
Too much animation GIFs may also distract some users from reading the page.
Make sure the page contains no animated GIF with a refresh rate of between 2 to 55 frames per second. In other words, make sure no image repeatedly flashes or changes from dark to light from 2 and 55 times per second.
If you need to use the animated GIF, increase its refresh rate to more than 55 frames per second or change its colors to reduce the flickering effect.
The page contains a graphic object that may cause the
screen to flicker.
Make sure the page does not contain an animated object
with a refresh rate of between 2 to 55 frames per second.
A flickering or flashing screen may cause seizures in users with photosensitive epilepsy. As a result, content developers should avoid causing the screen to flicker.
Seizures can be triggered by a light flickering or flashing 2 to 55 times per second, with peak sensitivity at 20 flashes per second with quick changes from dark to light.
Here are HTML elements that may cause flickering:
Make sure no animated object has a refresh rate of between 2 to 55 frames per second. In other words, make sure no image repeatedly flashes or changes from dark to light from 2 and 55 times per second.
If you need to use the animated object, increase its refresh rate to more than 55 frames per second or change its colors to reduce the flickering effect.
The page contains OBJECT elements embedding images that do not have a valid description between the <OBJECT> and </OBJECT> tags.
A valid description is an HTML fragment between the <OBJECT> and </OBJECT> tags that contain the following:
A valid description does not contain placeholder text (see http://www.w3.org/TR/AERT#AppendixC).
The OBJECT tag offers a mechanism for specifying alternate object renderings. Each embedded OBJECT declaration may specify alternate content types. If a browser cannot render the outermost OBJECT, it tries to render its contents, which may be another OBJECT element, etc.
At least one object in such a chain should be accessible by providing a valid equivalent description so that users without graphics-enabled browsers can still effectively navigate the page. The advent of hand-held, text-only browsers makes the use of the ALT descriptions more important now than ever.
Defining a textual description for an object can also improve the page listing in some search engine.
Insert a meaningful description inside the <OBJECT> tag.
The alternative textual description should explain the content of the image and its role in the document.
The OBJECT elements embedding images in this document should have corresponding equivalent description between the <OBJECT> and </OBJECT> tags.
The OBJECT element offers a mechanism for specifying alternate object renderings. Each embedded OBJECT declaration may specify alternate content types. If a browser cannot render the outermost OBJECT, it tries to render its contents, which may be another OBJECT element, etc.
Objects that embed images should have corresponding equivalent descriptions or images to allow users without graphics-enabled browsers to still effectively navigate the page.
The image description should convey the same information as the image and it should explain the role the image plays on the page: why it is there, what it represents, how it presents the information.
Insert an equivalent meaningful textual description inside the <OBJECT> tag, or insert an image.
The alternative textual description should explain the content of the image and its role in the document.
The page contains OBJECT elements embedding audio or video files without a valid description between the <OBJECT> and </OBJECT> tags.
The OBJECT element's design offers a mechanism for specifying alternate object renderings. Each embedded OBJECT declaration may specify alternate content types. If a browser cannot render the outermost OBJECT, it tries to render the contents, which may be another OBJECT element, etc.
Objects included in this document that embed audio or video files do not have corresponding valid descriptions. A valid description is an HTML fragment between the <OBJECT> and </OBJECT> tags that contain the following:
A valid description doesn't contain placeholder text (see http://www.w3.org/TR/AERT#AppendixC).
Insert a meaningful description inside the <OBJECT> tag.
The alternative textual description should be a transcription of the audio/video file.
The OBJECT elements with embedded audio or video files included in this document should have corresponding equivalent description between the <OBJECT> and </OBJECT> tags.
Equivalent descriptions for sounds can be provided in the form of a text phrase on the page that links to a text transcript or description of the sound file. The link to the transcript should appear in a highly visible location such as at the top of the page. If a script automatically loads a sound, the script should also automatically load a visual indication that the sound is currently playing and provide a description or transcript of the sound.
The OBJECT element's design offers a mechanism for specifying alternate object renderings. Each embedded OBJECT declaration may specify alternate content types. If a browser cannot render the outermost OBJECT, it tries to render the contents, which may be another OBJECT element, etc.
Insert a meaningful description inside the <OBJECT> tag.
In particular, check the content inside the <OBJECT> and </OBJECT> tags:
The page contains OBJECT elements without a valid description between the <OBJECT> and </OBJECT> tags.
The OBJECT element's design offers a mechanism for specifying alternate object renderings. Each embedded OBJECT declaration may specify alternate content types. If a browser cannot render the outermost OBJECT, it tries to render the contents, which may be another OBJECT element, etc.
Objects included in this document do not have corresponding valid descriptions. A valid description is an HTML fragment between the <OBJECT> and </OBJECT> tags that contain the following:
A valid description does not contain placeholder text (see http://www.w3.org/TR/AERT#AppendixC).
Insert a meaningful description inside the <OBJECT> tag.
The ALT description should convey the same information as the object embedded, and it should explain the role the object plays on the page: why it is there, what it represents, how it presents the information.
The description contained between the <OBJECT> and </OBJECT> tags of the OBJECT elements on the page should be an equivalent description of the objects themselves.
The OBJECT element's design offers a mechanism for specifying alternate object renderings. Each embedded OBJECT declaration may specify alternate content types. If a browser cannot render the outermost OBJECT, it tries to render the contents, which may be another OBJECT element, etc.
Insert a meaningful description inside <OBJECT> tag.
The ALT description should convey the same information as the object embedded, and it should explain the role the object plays on the page: why it is there, what it represents, how it presents the information.
The page contains elements such as OBJECT or EMBED tags embedding multimedia files or elements referring directly to them (such as A or AREA tags).
Make sure equivalent alternatives such as captions or auditory descriptions of the visual track are synchronized with the multimedia presentation.
Auditory presentations must be accompanied by text transcripts or textual equivalents of auditory events. When these transcripts are presented synchronously with a video presentation, they are called captions and are used by people who cannot hear the audio track of the video material.
Some media formats such as QuickTime 3.0 and SMIL allow captions and video descriptions to be added to the multimedia clip. SAMI allows captions to be added.
Until the format you are using supports alternative tracks, two versions of the movie could be made available - one with captions and descriptive video, and one without. Technologies such as SMIL and SAMI allow separate audio/visual files to be combined with text files through a synchronization file to create captioned audio and movies.
Some technologies also allow the user to choose from multiple sets of captions to match their reading skills. For more information see the SMIL 1.0 specification at http://www.w3.org/TR/1998/REC-smil-19980615/.
The page contains elements such as OBJECT or EMBED tags
embedding multimedia files or elements referring directly
to them (such as A or AREA tags).
Make sure the following requirements are met:
The page contains elements such as OBJECT or EMBED tags embedding multimedia files or elements referring directly to them (such as A or AREA tags).
Make sure auditory descriptions are provided for every visual track in the multimedia presentation.
Generally, multimedia presentations require users to rely on more than one sense, such as combining a reliance on hearing and vision. While these advances make web pages more interesting and "layered" for people without disabilities, those with disabilities face new barriers to understanding a page's content.
To ensure multimedia is accessible to users with visual impairments, you should ensure that audio descriptions of video portions are provided in all cases, except where the video portion of a presentation is unimportant to understanding a presentation.
Auditory descriptions of the visual track provide narration of the key visual elements without interfering with the audio or dialogue of a movie. Key visual elements include actions, settings, body language, graphics, and displayed text.
Until the format you are using supports alternative tracks, you could add a link to an existing audio description file.
The page contains elements such as OBJECT or EMBED tags embedding multimedia files or elements referring directly to them (such as A or AREA tags).
Make sure audio descriptions are provided for all important visual information as:
Consistent page layout, recognizable graphics, and easy to understand language will benefit all users. In particular, they help people with cognitive disabilities or who have difficulty reading.
Using clear and simple language promotes effective communication. Access to written information can be difficult for people who have cognitive or learning disabilities. Using clear and simple language also benefits people those whose first language differs from your own, including those people who communicate primarily in sign language.
The following are some writing style suggestions to help make the content of your site easier to read:
To help determine whether your document is easy to read, consider using the Gunning-Fog reading measure, available at http://isu.indstate.edu/nelsons/asbe336/PowerPoint/fog-index.htm. When fed a text, this algorithm generally produces a lower score when content is easier to read. If you find your score soaring into the teens (or higher!), you've lost most of your audience in the dense fog.
Make sure the text on the page is easy to read by everyone, especially by people with reading or cognitive disabilities.
If the page contains chunks of text written using different languages such as English, French, or Spanish, then every chunk should be contained in a tag with a LANG attribute.
If you use different natural languages on a single page, make sure any language switch is clearly identified with the LANG attribute.
Identifying language switches on a page is important for the following reasons:
It is also important because more and more sites will be accessed through audio-only devices such as telephones.
The LANG attribute may be helpful in many other situations, such as the following:
Clearly identify changes in the natural language used in the text of a document and any text equivalents as follows:
The page contains A or AREA elements pointing to audio files.
Make sure the audio file is described within the document, or that the document contains a link to a transcript file or to a file containing a description of the sound file.
Text equivalents for sounds can be provided as textual links to a text transcript or a description of the sound file. The link to the transcript should appear in a highly visible location such as at the top of the page.
Unless transcripts are provided, the following users could not hear the audio's output and take advantage of its contents:
Insert a meaningful description of the audio file.
In particular, make sure the page contains one of the
following:
The page contains proprietary tags that are replaced by a web server by one or more HTML tags. As a result, it is not possible to check the accessibility of the original file. A thorough evaluation requires testing the final version of the page, which can be done by opening the page in a browser, saving it, and testing the saved version.
Some web technologies such as ColdFusion use specialized tags to create specific kinds of information and behaviors. When the server receives a request for the page, the server replaces all the specialized tags with HTML and then sends the page to the user's browser. The page the user receives should no longer contain any proprietary tags.
It may not be possible to check the accessibility of a page for the following reasons:
For these reasons, it is not always possible to completely check the accessibility of a page in its original state. You must test it in its final state.
Using a browser, request the page from the server. The page that opens in your browser should no longer contain any proprietary tags. Save the page using the browser's save command (in Microsoft Internet Explorer, choose File > Save As), then test the saved version for accessibility.