5 FAH-8 H-500
accessibility and usability
5 FAH-8 H-510
accessibility (section 508 compliance)
(CT:WEB-32; 07-24-2024)
(Office of Origin: GTM/OAA)
5 FAH-8 H-511 SCOPE AND REFERENCES
(CT:WEB-3; 05-09-2008)
The purpose of this chapter is to provide further guidance on the requirements set forth in 5 FAM 915.7, which implements Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires all Federal agencies to ensure that electronic and information technology that they develop, procure, maintain or use is accessible to people with disabilities. For a list of relevant authorities, see 5 FAM 912. Find and key definitions in 5 FAM 913.
5 FAH-8 H-512 compliance (section 508)
(CT:WEB-31; 07-10-2024)
a. The DT Program for Accessible Computer/Communication Technology (IMPACT) (DT/BMP/GRP/SM/IMPACT) is the Department’s primary authority and resource for achieving electronic and information technology (EIT) accessibility for all employees and customers, which includes providing assistance to all bureaus in their implementation of Section 508. IT project managers, Webmasters, content managers, developers, and others involved in the procurement or development of EIT should utilize this resource by retrieving information and training materials off of IMPACT’s Intranet site or by requesting assistance via e-mail at section508@state.gov.
b. Related information and training materials can be found on the General Services Administration’s (GSA) 508-specific Web site and on the Access Board’s Web site.
5 FAH-8 H-513 ACCESSIBILITY
(CT:WEB-3; 05-09-2008)
a. While 29 U.S.C. 794d and 36 CFR 1194 do not provide a legal definition of “EIT accessibility,” they describe the Federal legislative mandate for accessible EIT and Technical Standards (i.e., the measures of EIT compliance with Section 508). Operationally, “EIT accessibility” generally can be understood as the relational state achieved between the user with disability, the user’s given adaptive technology (AT), and the designed user interface (UI), when users with disabilities can gain comparable access to and the use of the functionality and information of an EIT product (e.g., a Web application, broadcast/multimedia production, document, or site). Disabilities include:
· Visual limitations
· Perceptual limitations
· Physical disabilities
· Auditory deficiencies
· Inability to decode complex patterns
· Attention deficiencies, and
· Hardware capability.
b. Web designers should use technology to compensate for a physical disability (e.g., screen reader, Braille display, magnification software, or speech-recognition system).
c. Web designers should minimize use of technology that creates new problems for persons with disabilities. When providing alternative means to access a Web application, page, or site, the developer must find the least common denominator among hardware, peripherals and/or special devices, and software applications.
c. Web designers should write for worldwide audiences to avoid users quitting a site because the site contains:
(1) Unintelligible instructions;
(2) Idiomatic language unlikely to be understood by world-wide users;
(3) Multimedia content lacking sufficient captioning, or
(4) Content requiring technology or very high bandwidth not readily available to world-wide users who rely on older, slower technology to access and use the Internet.
d. In general, Web designers should create and design products easy to access, use, navigate, and understand; wherever possible, keep it simple. Web products that are too complex or tedious for users to understand can lead to frustration and will likely adversely affect user access, use, or navigation of that content.
5 FAH-8 H-514 ACCESSIBILITY STANDARDS
(CT:WEB-3; 05-09-2008)
The Architectural and Transportation Barriers Compliance Board (the Access Board) interprets 36 CFR Section 1194.22 (a) through (k) as consistent with the priority 1 checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the World Wide Web Consortium (W3C) Web Accessibility Initiative. 36 CFR Section 1194.22 (l) through (p) are not priority 1 checkpoints in WCAG 1.0 and should be addressed separately by the Department of State Web site developers.
|
Section 1194.22 Paragraph |
WCAG 1.0 Checkpoint |
|
(a) |
1.1 |
|
(b) |
1.4 |
|
(c) |
2.1 |
|
(d) |
6.1 |
|
(e) |
1.2 |
|
(f) |
9.1 |
|
(g) |
5.1 |
|
(h) |
5.2 |
|
(I) |
12.1 |
|
(j) |
7.1 |
|
(k) |
11.4 |
5 FAH-8 H-515 STATUTORY REQUIREMENTS
(CT:WEB-3; 05-09-2008)
a. At minimum, the following Section 508 technical requirements at 36 CFR 1194.22 are mandatory on all Department of State Web products (e.g., applications, broadcast/multimedia productions, documents, pages, or sites). While examples are provided to demonstrate possible ways to satisfy each requirement at 1194.22, they are not necessarily the only acceptable solutions.
b. Furthermore, you should follow other requirements from Section 508 which may be applicable but not covered in detail in this section.
c. In some cases, for example, such as with some Web applications (e.g., Java or AJAX applications), you should also meet requirements from section 1194.21.
d. The requirements at 36 CFR, section 1194.31 “Functional-Performance Criteria” are applicable (like meta-requirements) to all or nearly all EIT products. You should consider, test against, and meet at least these practical success criteria before release of the production version of the Web product.
e. The requirements under 36 CFR, section 1194.41 may be applicable as well, especially in cases of some Department or bureau-specific Web applications.
f. Department IT project managers and developers can read what these additional Section 508 requirements are and document and/or track the level of conformance of their Web products to these requirements by using, modifying as needed, and filling in a 508 requirements checklist known as Government Product Accessibility Template (GPAT) at the IMPACT Web site. In most cases, the Detailed Tables 1194.23 through 1194.26 will not apply and, in such cases, may be removed from the GPAT. However, use ‘Not Applicable’ (NA) for each of these Sections in column 2 of the Summary Table. Please use Appendix A near the bottom of the GPAT for a range of responses (e.g., 'Not Applicable') and their definitions that drafters should use in filling in column 2 of the various tables. For further assistance please contact IMPACT staff at section508@state.gov or 202.663.0221.
5 FAH-8 H-515.1 Alternative Text Descriptions
(CT:WEB-7; 03-15-2013)
a. You must provide meaningful text or words to denote or describe the purpose, function, or information conveyed by a nontext element (see36 CFR, section 1194.22(a). In cases where the nontext element triggers an action, the description must also indicate what that action is. An example of an active element is a link that is depicted as an image rather than words. Nontext elements include items such as applets, images, image maps, frames, video files, and audio files.
b. The alt parameter is used with the <applet>, <area>, <img>, <embed>, <object>, and <input> tags to provide a short description of the element. The alt parameter text shows on the screen when the mouse is focused on the element.
|
Example <img src="Seal.gif" alt="Picture of the Department seal">
|
Descriptive text should be concise and less than seventy (70) characters long. Images that do not provide content such as spacers, bullets, and arrows should use alt=”” so they will be ignored by adaptive devices.
c. Unimportant graphics (i.e., spacer gifs) should have an ALT tag, but no description (alt=””).
d. The longdesc (url) parameter is used with the <img>, <frame>, and <iframe> tags to provide a detailed description of the element. Unlike the alt parameter, the long description does not display on the screen. It is available to screen readers and other forms of assistive technologies; however, some screen readers have a 150-character limit.
|
Example <img src="Seal.gif" longdesc="http://www.state.gov/eagle_desc.html">
|
e. When the description exceeds 150 characters, you may use an alternative method—a descriptive link. Making it the same color as the background will hide the descriptive link from view while allowing a screen/Braille reader to identify it.
|
Example <style> a.hide { color: #FFFFFF; } </style>
<img src="Seal.gif" alt="Picture of the Department seal"> <a class="hide" href="http://www.state.gov/eagle_desc.html">Description of the Department seal</a>
|
f. The alternative to using either parameter is to provide a description of the element as part of the Web page or in the case of an <applet>, within the applet tags.
|
Example <p>The State Department Seal consists of the Great
Seal of the United States with a ring around it. The ring in this view is
simulated by the words "Department of State United States of
America."</p>
|
|
Example <applet code="travelapplet.class" width="200", height="100" alt=”This applet displays current travel restrictions for the selected country”> </applet>
|
g. Audio and video files may be displayed separately and not qualify under the multimedia requirements; however, they are still nontext elements and must have alternate text equivalents. For audio files, there should be a link to a text translation. Animated video files should have a long description attached to explain what action is taking place and why it is important to the Web page. Inanimate video files (e.g., a PowerPoint presentation) incapable of interpretation by adaptive technology should have alternate text attached to each page.
5 FAH-8 H-515.2 Alternative Text Pages
(CT:WEB-3; 05-09-2008)
a. In some cases, the content of a page may require the Web designer to use features that cannot be made accessible even using assistive technologies. If this situation occurs, the Web designer must include a link to a text-only alternate page that allows full access to people with disabilities. The text-only page must contain equivalent information or functionality as the primary pages and must be updated as often as the primary page (see 36 CFR, section 1194.22(k)).
c. To ensure a Web site is accessible, Web designers should consider enlisting the aid of someone familiar with assistive technologies to test the pages. This should be done with a text-only browser such as Lynx, which may be used to ensure the text-only pages are understandable. Please contact IMPACT staff at section508@state.gov for assistance with this requirement.
5 FAH-8 H-515.3 Multimedia Presentations
(CT:WEB-3; 05-09-2008)
a. Synchronize equivalent alternatives for any multimedia presentation with the presentation (see 36 CFR, section 1194.22(b)).
b. The evolution of multimedia technologies allows presentations, short movies, other content with synchronized audio and video tracks, and real time programming in the form of streaming audio and video. While the combining of multiple senses, such as hearing and vision, may make a Web page more interesting for people without disabilities, it presents new challenges when making pages accessible to people with disabilities
c. Captioning for the audio portion and audio description of visual information of multimedia presentations are considered equivalent alternatives. When an audio portion of a multimedia production is captioned, synchronize captioning with the audio. Synchronized captioning is required so that those reading captions may also watch the speaker and associate relevant body language with speech (see 5 FAH-8 H-514.1 and 36 CFR, section 1194.22(a)).
5 FAH-8 H-515.4 Use Of Color
(CT:WEB-7; 03-15-2013)
a. Design Web pages so that all information conveyed with color is also available without color, for example from context or markup (see 36 CFR, section 1194.22(c)).
b. Color deficiency falls primarily into two categories, red/green and yellow/blue, while total color blindness or the ability to see only shades of gray is very rare. The vast majority of color deficient persons experience problems with red/green discrimination. Maps and charts, as well as their legends, are problem areas related to the inability to distinguish colors or shades of colors.
c. Exclusive use of "stop light" colors to show the status of a project is inappropriate. Example 1 is unacceptable. Examples 2 and 3 are marginally acceptable. There is a contrast problem between the black text and the background colors for the red and green circles in example 2, and the color names convey no meaning in example 3. Example 4 provides the best solution to concurrent content and color presentation.
|
|
5 FAH-8 H-515.5 Style Sheets
(CT:WEB-3; 05-09-2008)
a. Organize documents so they are readable without requiring an associated style sheet. (see 36 CFR, section 1194.22(d)).
b. Some browsers allow the user to specify a default style sheet. Information contained in that style sheet sets the screen size, text size, and color options to facilitate viewing of Web pages. A Web page that overrides the local options may make the page inaccessible through interference with the user's ability to view the page. Web page designers must ensure that their Web pages do not interfere with user-defined style sheets.
c. Style sheets, not tables, should be used to create the basic layout of the Web site. A Web site that has a top banner and three columns can be defined and used on a Web page as shown in the following examples:
|
Example
|
|
Example <body> <div id="top"> <!-- banner images and/or text --> </div> <div id="left"> <!-- left column information --> </div> <div id="right"> <!-- right column information --> </div> <div id="center"> <!-- center column information --> </div> </body>
|
5 FAH-8 H-515.6 Image Maps
(CT:WEB-7; 03-15-2013)
a. Provide redundant text links for each active region of a server-side image map (see 36 CFR, section 1194.22(e)).
b. Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape (see 36 CFR, section 1194.22(f)).
c. Image maps are graphic images with one or more regions defined to act as a link or to initiate a script. The example (below) demonstrates two features that must be included with an image map:
(1) Define alternative text descriptions for each active region of the map. To do so, include the alt parameter in the area tags that define the active areas. To account for inactive areas the <img> tag (first line in the example) should also include an alt parameter. The alternate text description for the "Level 1" image map area is shown in the white block on the illustration.
(2) Include a redundant list of links associated with the image map to accommodate assistive technologies that do not recognize the image map. To avoid confusion, locate the redundant list adjacent to or immediately below the image map.
|
Example <img src="OrgChart.jpg" usemap="#org_map" ismap alt="Organizational Chart">
<dir> <a href="#L1">Level 1 description</a><br> <a href="#L2a">Level 2a description</a><br> <a href="#L2b">Level 2b description</a><br> <a href="#L3a1">Level 3a1 description</a><br> <a href="#L3a2">Level 3a2 description</a><br> <a href="#L3b1">Level 3b1 description</a><br> <a href="#L3b2">Level 3b2 description</a> </dir>
<!-- Organization Chart image map --> <map name="org_map"> <area shape="rect" coords="8,8,62,35" href="#L1" alt="Link to Level 1 description"> <area shape="rect" coords="98,54,156,82" href="#L2a" alt="Link to Level 2a description"> <area shape="rect" coords="98,148,156,176" href="#L2b" alt="Link to Level 2b description"> <area shape="rect" coords="202,31,259,60" href="#L3a1" alt="Link to Level 3a1 description"> <area shape="rect" coords="202,77,259,106" href="#L3a2" alt="Link to Level 3a2 description"> <area shape="rect" coords="202,127,259,156" href="#L3b1" alt="Link to Level 3b1 description"> <area shape="rect" coords="202,173,259,202" href="#L3b2" alt="Link to Level 3b2 description"> </map>
|
|
|
|
Illustration
|
d. The form of an image map called a server-side image map is characterized by identifying where on the viewer's screen an image will appear and the server generating the points that are used to identify the active areas. Undesirable features of this method include extra time required for the server to generate the points and the inability to use alternate text descriptions. To avoid problems associated with interpreting server-side image maps, they must not be used on Department of State Web sites.
5 FAH-8 H-515.7 Tables
(CT:WEB-7; 03-15-2013)
a. Identify row and column headers for data tables (see 36 CFR, section 1194.22(g)).
b. Use markup to associate data cells and header cells for data tables that have two or more logical levels of row or column headers (see 36 CFR, section 1194.22(h)).
c. Tables are designed to display numeric or textual data in tabular form. They are not intended to be a tool for graphical design of a Web page. Web site developers should use style sheets as an alternative to complex series of nested tables for defining the graphic layout of the Web site (see 5 FAH-8 H-514.5).
d. Do not use <pre> to format a table. Screen readers cannot identify a table structure from the stream of characters in the preformatted text and will not be able to associate row and column relationships for the vision impaired user.
e. Use either the "scope" attribute or the "id" and "header" attributes to associate table cells with the row and column headings.
f. "Scope" attributes are identified in the column headings (<th> tags) and in the first column of each row (<td> tags). They are entered only once for each column or row.
|
Example <table> <tr> <th> </th> <th scope="col">Overdue</th> <th scope="col">On time</th> <th scope="col">Early</th> </tr> <tr> <td scope="row">Project 1</td> <td>date</td><td>date</td><td>date</td> </tr> <tr> <td scope="row">Project 1</td> <td>date</td><td>date</td><td>date</td> </tr> <tr> <td scope="row">Project 1</td> <td>date</td><td>date</td><td>date</td> </tr> <tr> <td scope="row">Project 1</td> <td>date</td><td>15 June 03</td><td>date</td> </tr> </table>
|
|
Example The scope attributes associate the date with "Project 1" and "On time".
|
The "id" and "header" attributes perform the same function as "scope" attributes but are more complicated to use. A unique "id" attribute must be entered for each column and row. Each cell must include a "header" attribute showing the value of the associated column and row ids.
|
Example <table> <tr> <th> </th> <th id="overdue">Overdue</th> <th id="ontime">On time</th> <th id="early">Early</th> </tr> <tr> <td id="proj1">Project 1</td> <td headers="proj1 overdue">date</td> <td headers="proj1 ontime">date</td> <td headers="proj1 early">date</td> </tr> <tr> <td id="proj1">Project 2</td> <td headers="proj2 overdue">date</td> <td headers="proj2 ontime">date</td> <td headers="proj2 early">date</td> </tr> <tr> <td id="proj1">Project 3</td> <td headers="proj3 overdue">date</td> <td headers="proj3 ontime">date</td> <td headers="proj3 early">date</td> </tr> <tr> <td id="proj1">Project 4</td> <td headers="proj4 overdue">date</td> <td headers="proj4 ontime">15 June 03</td> <td headers="proj4 early">date</td> </tr> </table>
|
5 FAH-8 H-515.8 Frames
(CT:WEB-3; 05-09-2008)
a. Frames shall be titled with text that facilitates frame identification and navigation. (36 CFR, section 1194.22(i)).
b. To ensure that Web pages using frames are accessible to people with disabilities, designers should use the title attribute to provide meaningful titles to each of the frames so users can properly orient themselves. Otherwise, those who use screen readers or other assistive technologies will be unable to fully understand the relationships among multiple frames on the same page.
c. A <NOFRAME> option must be provided whenever a <FRAME> is used. Where appropriate, the <NOFRAME> option should provide links to standalone versions of the <FRAME> content.
5 FAH-8 H-515.9 Screen Flicker
(CT:WEB-3; 05-09-2008)
a. Design pages to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz (see 36 CFR, section 1194.22(j)).
b. The condition to which this requirement pertains to is called photosensitive epilepsy. It occurs in less than 5% of people afflicted with epilepsy with the onset occurring below the age of twenty years old. It can be triggered by either natural or artificial light flashing in the range of 2-59 flashes per second.
c. Although the most common cause of a seizure is a television set, the TV characteristics that can precipitate a seizure do not extend to the video display unit (VDU) or computer monitor. Computer monitors have scan frequencies above 60 Hz and liquid crystal displays (LCD) are flicker free. The actual risk depends on the material being displayed and is added through innovations such as animated gif's, Java applets, and third-party applications.
d. Web page developers must not use strobe light effects or animations which flicker or flash at rates between 2 and 59 flashes per second. This includes but is not limited to
changing from dark to light
changing between different colors or patterns
oscillating motion of an image
In addition to animation, the <BLINK> and <MARQUEE> tags can cause a strobing effect and should be avoided.
5 FAH-8 H-515.10 Scripts And Plug-ins
(CT:WEB-7; 03-15-2013)
a. When pages utilize scripting languages to display content, or to create interface elements, identify the information provided by the script with functional text that can be read by assistive technology (see 36 CFR, section 1194.22(l)).
b. 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 Federal requirements (see 36 CFR, section 1194.21(a) through (l) and also 36 CFR, section 1194.22(m)).
c. Scripts (including but not limited to ASP, JavaScript, PERL, PHP, and VB script) must be designed to meet the requirements of 5 FAH-8 H-514.10, paragraph a. One of the major problems with scripts is the inability to provide meaningful information about the script's functionality. Frequently, the simple solution is the easiest and best method to provide accessibility:
(1) Calling a function as a link allows a screen reader to tell the user what is happening;
|
Example <a href="javascript:myFunction();">Start
myFunction</a> |
(2) The same code done with an image (example A) does not provide the same information unless a meaningful description is included in either the <img> "alt" attribute or the <a> "title" attribute (example B).
|
Example A <a href="javascript:myFunction();"><img src="myFunction.gif"></a>
|
|
Example B <a href="javascript:myFunction();"> <img src="myFunction.gif" alt="picture link for starting myFunction"></a> <a title="this link starts myFunction" href="javascript:myFunction();"> <img src="myFunction.gif"></a>
|
d. Not all event handlers are supported by screen readers, and there is no standardization among those that are supported.
|
OnClick |
Do not use the onClick event handlers for form elements that include several options (e.g., select lists, radio buttons, checkboxes) |
|
OnMouseOver OnMouseOut |
Neither event handler interferes with accessibility; however, if the effect (e.g., rollover gif) provides significant information, an alternate way to communicate that information must be available. |
|
onChange |
Do not use the onChange event handlers for triggering JavaScript functions based on a selection from within a <select> tag. If necessary to run a function based on a specific selection, use the OnClick event handler associated with a link or button placed adjacent to the <select> tag. |
e. Plug-ins provide common ways for Web developers to display different media (e.g., Acrobat Reader to display .pdf files and Real Audio to play audio and video files). Web developers must ensure that any plug-ins required to access Web page content are compliant with accessibility standards. Noncompliant plug-ins must not be used. Web developers must also provide a link to the source of each required plug-in.
f. Plug-ins used on OpenNet+ must be approved by the IT Configuration Control Board (IT CCB).
5 FAH-8 H-515.11 Forms
(CT:WEB-7; 03-15-2013)
a. When electronic forms are designed to be completed on-line, the form must 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 (see 36 CFR, section 1194.22(n)).
b. Users must be able to complete all forms by using any one of multiple input devices, at least one of which must be the keyboard, and using assistive technology. Web developers should exercise caution when using scripts to alter the content of functionality of a form or to automatically submit a form. Intrinsic events such as "onClick" and "onFocus" can produce confusing results for a user who is not able to fully comprehend them.
c. The first technique to accessible forms is the physical layout on the page.
|
Example
|
d. The three data elements placed side-by-side can be confusing as a screen reader tells you the label of all three blocks at once rather than identifying them individually. The example below provides a better physical layout.
|
Example
|
e. To ensure the blocks are correctly identified, each one should have an associated label tag. This is done by adding an "id" parameter to the form elements (<input> in this example) and enclosing the descriptive text with a <label> tag.
|
Example <table> |
f. In some cases, groups of form elements are associated with sets of data. To indicate the relationship, use the <fieldset> tag with a <legend> tag.
|
Example <table> |
|
|
|
Example
|
g. In addition to an accessible layout, clear and understandable instructions must be provided for entering data on each form. On simple forms, the instructions may be placed at the top of the form. The instructions for more complex forms should be divided into logical units and each unit placed near the associated input fields.
h. Department of State Web pages will not use javascript jump menus for linking to other pages. Script menus are not keyboard accessible because the user cannot scroll through the list. Menus generated by other scripting languages should be tested to ensure they can be accessed by people using assistive technology and through any one of multiple input devices, including the keyboard.
5 FAH-8 H-515.12 Repetitive Navigation Links
(CT:WEB-3; 05-09-2008)
a. Provide a method that permits users to skip repetitive navigation links (see 36 CFR, section 1194.22(o)).
b. Repetitive navigation links are typically found in a column on the left side of the Web page or in a row near the top of the page. The lists of links are repeated on all pages of the Web site to facilitate moving directly to new subject areas and are processed by the screen reader on each page.
c. A style sheet entry setting the text color the same as the background color provides the ability to hide the navigation link so only the screen reader will recognize it.
|
Example a.hide { |
d. The link to skip the repetitive navigation points to an anchor at another location on the Web page.
|
Example <a class="hide" href="#text"
title="Skip navigation">Skip navigation</a>. |
5 FAH-8 H-515.13 Timed Responses
(CT:WEB-3; 05-09-2008)
a. When a timed response is required, alert the user and give sufficient time to indicate more time is required (see 36 CFR, section 1194.22(p)).
b. In a slide show where each slide is set to display for a fixed period of time and contains much information to read and digest, a user with a cognitive disability may not be able to read and understand all the material within the allotted time.
c. When a Web application, page, or site is set to "time out," designers must alert the user before the time expires and give her or him an opportunity to request additional time.
5 FAH-8 H-516 Through H-519 Unassigned
(CT:WEB-3; 05-09-2008)