| Home |
 |
This chapter contains the electronic and information technology (EIT) performance requirements related to the following:
EIT Technical Standard 1194.22, Web-Based Intranet and Internet Information and Applications, Provisions (a) thru (p).
The requirements in this chapter cover the following:
• All information technology solutions, regardless of size or whether purchased or developed.
• Web-based applications and all associated data, information, training material, and documents.
Note: For EIT, requirements in more than one chapter of this handbook may apply. For instance, applications designed for both stand-alone and Web browser environments may require compliance with the standards on software application and operating system accessibility (chapter 5). Applications that include calls to video or multimedia or that are part of software that runs in self-contained platforms or in kiosks may require consideration with other chapters. And for applications designed to create output beyond direct interaction with the application itself (e.g., reports, data files, or media objects), developers must verify that these outputs are also accessible to users of assistive technology.
This chapter applies to anyone who buys or develops Web-based information and applications for the Postal Service (i.e., Postal Service employees, vendors, contractors, and business partners). Web-based information and applications include information technology solutions of all scope and magnitude, consisting of simple or complex purchases or development of Web-based applications and all associated data, information, training material, and documents.
Each subchapter is dedicated to a provision that supports the EIT Technical Standard.
Each provision has sections on rationale, techniques, testing, and references, as shown below in section 6-2.
6-1, Overview
6-2, Non-text Elements
6-3, Multimedia
6-4, Color
6-5, Style Sheets
6-6, Image Maps
6-7, Tables
6-8, Frames
6-9, Screen Flicker
6-10, Equivalent Text Content
6-11, Scripting Languages
6-12, Plug-ins and Applets
6-13, Forms
6-14, Portable Document Format (PDF)
6-15, Repetitive Navigation
6-16, Timed Responses
Appendix 6-A, Checklist
Accessibility is accomplished by designing software that accommodates the widest range of users, including those with disabilities. Listed below are some general requirements that will help the Postal Service ensure that Web-based applications and information remain accessible:
• The Postal Service will take advantage of operating system and Web client built-in accessibility features when those features are available to both end users and software developers.
• The Postal Service will maintain standards for the following accessibility aids or assistive technologies that are used by people with disabilities to access Web-based applications and information:
• Screen magnifiers: Help visually impaired people by allowing them to enlarge any part of the screen (i.e., as with a magnifying glass).
• Screen readers: Help blind people by making on-screen information available as synthesized speech or for display as refreshable Braille.
• Voice input aids: Help mobility- or dexterity-impaired people by allowing them to control the computer with their voice instead of with a mouse or keyboard.
• On-screen keyboards: Help people who are unable to use a standard keyboard by providing an on-screen keyboard that can be used with a pointing device.
• Keyboard filters: Help people who have trouble typing by compensating for erratic motion, tremors, or slow response time.
• Alternative input devices: Help people who would prefer to control their computer with a device other than a keyboard or mouse.
• The Postal Service will develop Web-based applications that are based on interoperable specifications and do not interfere with accessibility features installed and activated by a user (e.g., operating system features and Web client capabilities as well as installed accessibility aids). Web-based developers should do the following:
• Support native operating system and activated accessibility features for major operating systems that are integrated with input and output devices (e.g., keyboard, sound, display, or mouse). These features are supported by most Web clients and Web browsers. Developers should be aware of how these features will be used in combination with Web-based technologies. Standards for each operating system related to each specific requirement are shown in the "References" area under each specific requirement in Chapter 5, Software Applications and Operating Systems.
• Use standard markup tags in creating Web content where possible (i.e., use the W3C recommendations). Standardized markup is often already supported by Web clients and operating system accessibility features. Using these tags will often eliminate the need for software to provide explicit accessibility support, unless the behavior of the Web content has been enhanced.
• Use caution when using plug-ins or enhancing Web content, because accessibility aids may have difficulty identifying them (i.e., accessibility aids require specific information to work successfully with screen elements). When custom or enhanced Web content is used, developers must use appropriate methods to allow Web content and information (e.g., providing alternate or equivalent content.) to function with accessibility aids. The nonproprietary information that is created using standard HTML, XHTML, XML, or SGML allows for access using multiple clients (tools), reduces development costs, and permits the interoperability of technologies unknown by the author or creator of the information. Provide flexibility by allowing for a variety of input (e.g., keyboard, mouse) and output (e.g., color, sound, images, text) methods.
• Allow accessibility aids and nonstandard clients to use and configure the Web applications and information automatically. For example, detecting a specific browser and providing additional modification of Web content should not prevent unknown clients and accessibility aids from accessing the content.
Handbook AS-885, usps.com Development Process and Standards, provides processes and standards for building and maintaining an information presence or application on usps.com and defines the design and development standards and best practices for use on that site. This handbook may be accessed online at http://blue.usps.gov/cpim/ftp/ hand/as885.pdf.
Postal Service employees are required to register all Web-based applications in the Enterprise Information Repository (EIR) at http://eir. This information will be used to report compliance and includes any related Section 508 noncompliance issues.
When testing Web-based applications and information for compliance, it is important to be aware that a Web-based application can only include only functionality supported by the Web client on which it executes. For example, a Web-based application running on the current generation of Web browsers can provide graphical functionality and support the most common Internet technologies. However, if those same users operate their computers a text browser, they are restricted to a primarily character-based environment with little graphical capabilities. It is crucial to be aware of the client browser environment the user is accessing when considering review and accessibility compliance with Section 508. In addition, it is important to be cognizant of the functionality available to users with disabilities via the accessibility aids available on the operating system in use.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools or integrated development environment (IDE) features can help automate these methods, but automated testing must be accompanied by manual testing. For example, a developer can use web tools to test for valid syntax (e.g., titling of all Web pages, hyperlink validation, inclusion of alternative text, or closing of tags), but a manual inspection must still be done to validate semantics and proper rendering. In other words, the meaningfulness of the Web page titles or alternative text must also be considered for the end user who uses assistive technology.
A descriptive text equivalent must be provided for all non-text elements that render information required for comprehension of the content, as well as those that facilitate navigation. Non-text items include images, video, graphs, charts, animation, and audio (Section 508, Provision §1194.22a).
Screen readers cannot interpret images without associated text.
Use the alt
attribute to provide a descriptive text equivalent that summarizes
the content of each non-text element. Review all content generated by tools
(i.e., exporting documents that contain images into HTML format) and
validate any HTML that is created. Tool-generated content must have all the
standard HTML required (such as proper header (TD and TH element
attributes), alt attributes, and valid HTML) to meet the provisions in this
handbook. Provide a text equivalent for animations using the alt attribute. If a
longer description is necessary, use the longdesc attribute or a "D-Link"
alternative.
Exhibit 6-2.2.1 (p. 1)
Example of Alternate Text for an Organization Chart
Figure A., Chart of the Leadership Team of the United States Postal Inspection Service Figure B. The text alternative for the chart in Figure A 4. Deputy Chief Inspector, Field Operations-South, A. Crawford |
Provide alternate descriptive text for images using the alt attribute of the <img> tag. The description should be usable in place of the image. It should contain equivalent information, so that if you did not have access to the image itself, the alternative text would convey the necessary meaning.
For images that are not used for comprehension or navigation or for images that are redundant, use a blank alt attribute to cause assistive technology to ignore the image. Examples of this include a block of color or a transparent graphic that is used as a filler or spacer, a design element, or an image used as a background.
Exhibit 6-2.2.2
Using the Alternate Image Attribute
The following graphic is a screen shot of an image that has an alt attribute associated with it.
Figure A. United States Postal Service logo with eagle. Figure B. HTML code for image in Figure A.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
Use the longdesc attribute when alternate descriptive text is not sufficient to adequately convey the information from a non-text element. The longdesc attribute provides a longer, more detailed description. This requires the creation of an additional HTML file that stores the more detailed information about the non-text element. The longdesc attribute is placed within an image <IMG> tag to link the description or data to the image.
The following graphic is a screen shot of an image that has a longdesc attribute associated with it. The code for this image immediately follows the screen shot.
Exhibit 6-2.2.3 (p. 1)
Using Long Descriptions
Figure A. Screen shot of a chart that describes the administrative and technical steps, and the coding process for canned and live requests Figure B. HTML code for the image in Figure A
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> Figure A is an example of a chart containing complex information that requires the use of the longdesc attribute. In this exhibit, the longdesc attribute refers to the following Web content: |
Exhibit 6-2.2.3 (p. 2)
Using Long Descriptions
Although using the longdesc is the recommended approach, another way to
provide a more detailed description of an image is the description link
("D-Link" or "D"). A "D-link" is a link, placed after the image itself, to a page
that describes the image. In the anchor tag used to link to the description,
use the title attribute to identify the link destination. For example: <img
title="Detailed information on the sales figures graph">
.
Descriptive links also involves providing usable naming of short hyper-text links. Consider the context of links, such as providing a link labeled "back" to return to the calling page, can be confusing when not clearly indicating purpose.
If you wish to hide the descriptive link with style sheets, use an inline style change to match the font color to the background color. If you use static HTML, then the font attribute is also an option.
The following graphic is a screen shot of an image that has uses the "D-Link" technique. The code for this image immediately follows the screen shot.
Exhibit 6-2.2.4
Using Descriptive Links and Appropriate Use of Blank Alternates
Figure A. D-Link Example - Pie Chart showing percentage of cars through toll booth. Figure B. HTML code for image in Figure A
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
The example in Figure B in exhibit 6-2.2.4 also shows the proper use of the blank alt attribute. The code illustrates how images used in Web content that may have no real meaning should be tagged with a blank alt attribute in the image tag. Make sure that you do not put a blank space between the quotation markes in the alt attribute.
Manual testing, using the testing methods described in this chapter, is mandatory, as it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Manually test for valid HTML markup.
• Use automated tools to test for valid HTML markup.
• Mouse over the image to verify that descriptive text appears for each image.
• Ensure that images (not used for comprehension and navigation) used for format only contain blank ALT tags.
• Turn images off in the browser. Each image used for comprehension or navigation must be replaced with its equivalent descriptive text.
• Click on the links provided by the longdesc attribute or "D-Link" to ensure that the user is taken to the appropriate description.
• If a non-text element is critical to the understanding of content, and an ALT tag description will be lengthy, provide a long description ("longdesc").
The following reference is provided for more information on this topic but must not be used in place of the Postal Service guidelines contained in this handbook. Also see Chapter 8, Video and Multimedia Products, of this handbook. If these references conflict with the above techniques, you must defer to the Postal Service guidelines.
• Text equivalents
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-text-equivalent
Provide equivalent alternate formats or alternate access methods for any multimedia presentation and synchronize them with the presentation (Section 508, Provision §1194.22b).
Audio content, without captions or transcripts, is not accessible to the hearing impaired. Videos, without text descriptions, are not accessible to the visually impaired. Audio and video combined is multimedia. Separately, audio and video are each subject to the non-text requirements. In both cases, information needs to be provided in an alternate format or access method.
Provide synchronized captions or transcripts of audio content.
Provide a descriptive text equivalent for audio clips if the information in the audio clip helps the user to interpret the content of the Web content. (See the requirements for non-text elements in section 6-2.)
Provide text and audio descriptions of the action occurring in the video. (See the requirements for non-text elements in section 6-2.)
Provide a link to any player or plug-in that is required to render multimedia.
Update alternate formats and access methods concurrently with the audio and video Web content.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Search for all audio and video objects. Ensure that each audio and video object has a corresponding equivalent accessible alternate format.
• Verify that the content of the alternate format or access method is equivalent to and updated concurrently with the content of the primary audio and video Web source. Ensure that no information has been lost and that the meaning has remained the same.
• Use screen reader software to ensure that the player or plug-in is accessible.
• Ensure that the plug-in or player itself is compliant with the Access Board's standard, 36 CFR 1194.21 (Software Applications and Operating Systems).
The following reference is provided for more information on this topic but must not be used in place of the Postal Service guidelines above. If these references are in conflict with the above techniques, you must defer to the Postal Service guidelines.
• Synchronize equivalents
http://www.w3.org/TR/WCAG10-TECHS/#tech-synchronize-equivalents
Web pages must be designed so that all information required for navigation or meaning is independent of the ability to identify specific colors (Section 508, Provision §1194.22c).
People who cannot differentiate between certain color combinations or have some other visual impairment may have difficulty navigating or interpreting content that depends on the ability to identify color.
When foreground and background colors are too close to the same hue, they may not provide sufficient contrast between colors.
Identify information in such a way that the message is not conveyed through color alone. For example, do not instruct a user to "select an item from those listed in green." Instead, relay that information without referring to color. Use colors and shades that have sufficient contrast.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Test the content without colors by viewing it with a monochrome monitor or changing the color scheme (i.e., change to "High Contrast White" (Control Panel > Display > Appearance > Scheme > High Contrast White).
• Ensure that the Web content information can be viewed when using high-contrast appearance settings (e.g., white on black).
• Print the page onto a black and white printer and review.
The following references are provided for more information on this topic but must not be used in place of the Postal Service guidelines above. If these references conflict with the above techniques, you must defer to the Postal Service guidelines.
• Colors
http://www.w3.org/TR/WCAG10-TECHS/#tech-color-convey
• Web/Computer Color Chart for the Colorblind
http://www.toledo-bend.com/colorblind/colortable.html
Documents must be organized so that they are readable without an associated style sheet. Documents must be constructed so that the user does not need style sheets to interpret the content of the Web page. This does not prohibit the use of style sheets (Section 508, Provision §1194.22d).
If not organized properly, style sheets may make it difficult for Web pages to be read accurately in browsers that do not support style sheets or in a browser in which a user has disabled support for style sheets. Visually impaired users may disable or overwrite style sheets so that the font size, colors, or contrast of the Web content is easier to read.
Style should affect the visual makeup of the document without affecting content. When considering the use of a table for page content layout, consider creating a style sheet instead. When Web content combines CSS with HTML layout, you must test both the accessibility of the content as developed and as modified by simulated user-enabled style sheets. The information conveyed must be understood when viewing the document without the associated style sheet.
Arrange style commands so that the contents make sense when read in the correct order without the associated style sheets. Make sure that the web content is useable when the style sheets have been disabled in the browser or the user has elected to activate their user-developed style sheets. If the content has changed or is not useable, provide an alternative Web page in an accessible alternate format. The following two examples show the use of style commands. The first example is incorrect because it only uses horizontal positioning. In the second example, both horizontal and vertical positioning are used which leads to proper ordering of the sentence, regardless of whether the style sheets are disabled.
Exhibit 6-5.2.1a
Example of an Incorrect Use of Style Sheets
Figure A. Screen capture of incorrectly formatted CSS Web content In this example, if a user elected to use his or her own style sheets, or if style sheets were disabled in the browser, the sentence would read incorrectly.
Figure B. HTML code for Figure A
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
Exhibit 6-5.2.1b
Example of Style Sheets Used Correctly
In this example, if a user elected to use his or her own style sheets, or if style sheets were disabled in the browser, the sentence would read correctly.
Figure A. Screen capture of correctly formatted CSS web content. Figure B. HTML code for Figure A
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Turn the style sheets off in the browser. Ensure that all content can be understood and that it is in the same logical order as intended by the author.
• Create a blank style sheet and configure your browser to use this style sheet to override all non-user-defined style sheets. Ensure that the resulting content can be understood using assistive technology and that it is in the same logical order as intended by the author.
The following reference is provided for more information on this topic but must not be used in place of the Postal Service guidelines given above. If these references conflict with the above techniques, you must defer to the Postal Service guidelines.
• Style sheet organization
http://www.w3.org/TR/WCAG10-TECHS/#tech-order-style-sheets
Use client-side image maps, whenever possible, in place of server-side image maps (Section 508, Provision §1194.22e). Provide equivalent redundant text links for all server-side image map hot-spot areas (Section 508, Provision §1194.22f).
Screen readers cannot read images. However, image maps can be made accessible if a descriptive text equivalent is provided for each hot-spot area.
A client-side image map contains all of the information about the image map. It is stored within the HTML document and interpreted through the browser.
The server-side image map is external to the HTML document. A server-side image map requires a script on a Web server that identifies the hot spots and their corresponding uniform resource locators (URL). When a server-side image map is used, browsers cannot indicate to the user which URL will be followed when a region of the map is activated.
Use the alt attribute within the <IMG> and <AREA> tags to provide a descriptive text equivalent for all hot-spot areas of a client-side image map.
Exhibit 6-6.2a
Example of a Client-Side Image Map
Figure A. Client-side image map The following graphic is a screen shot of an image map. The code for this client-side image map immediately follows the screen shot.
Figure B. HTML code for Figure A
<a href = "worldmap.map"> |
Exhibit 6-6.2b
Example of a Server-Side Image Map (With Redundant Text Links)
The following code is an example of a server-side image map. <a href="img/imgmap1.map"><img src="imgmap1.gif" alt="Please use the following links instead of this imagemap." ismap> </a> <br><br> [ <a href="a.htm">Section A</a> | <a href="b.htm">Section B</a> | <a href="c.htm">Section C</a> | <a href="d.htm">Section D</a> | <a href="e.htm">Section E</a> ] |
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Mouse over the active regions of the client-side image map to ensure that an equivalent text description appears for each hot spot.
• Verify that all redundant text links in a server-side image map work properly.
The following reference is provided for more information on this topic but must not be used in place of the Postal Service guidelines given above. If these references conflict with the above techniques, you must defer to the Postal Service guidelines.
• Redundant text links
http://www.w3.org/TR/WCAG10-TECHS/#tech-redundant-server-links
Tables must be constructed so that they can be easily interpreted by all users and communicate the intent of the author (Section 508, Provision §1194.22g, h).
Screen readers have difficulty interpreting data if the tables are not designed properly. A sighted person can scan down a column and across a row of a data table. For a visually impaired person, listening to this same information with a screen reader can be a daunting task. When tables are created using software for generating HTML pages (e.g., HTML editors or office suites), the underlying source code may not be accessible using screen reader software. The techniques outlined in section 6-7.2 must be applied regardless of the software used to generate HTML.
There are three general uses for tables: data tables (simple and/or complex data), document layout tables, and forms within data tables.
If a data table has one logical level of row or column headers, it is a simple table. Complex tables are data tables that have more than one logical level of row or column headers.
When a table is used for layout purposes, ensure that the layout is not required to understand the information. The page content layout should be transparent to the interpretation of the page content.
Forms within tables are addressed in section 6-13.
Use the <TABLE> tag primarily for the display of tabular data. Non-tabular tables may be used for layout if the table uses appropriate HTML to summarize the intent of the design.
Identify row and column headers for data tables. Associate data cells with their headers for all tables that have two or more logical levels of row or column headers. The table must be constructed so that it can be read logically from left to right and from top to bottom.
Where appropriate, use the <CAPTION> tag and/or the summary attribute for tabular data. It is not necessary to include summary attributes in data tables that are nested within a table. However, the outermost <TABLE> tag must contain a <CAPTION> tag and/or summary attribute. The content of the <CAPTION> tag is displayed on the screen. The contents of the summary attribute are read by the screen reader but not displayed on the screen.
If a data table has one logical level of row or column headers, it is a simple table. There are two options for coding simple tables. The first option is to use the table header <TH> tag and the id and header attributes. The id attribute within the <TH> tag is used in the first cell of each column to define the column header. The id attribute within the table data <TD> tag is used in the first cell of each row to define the row header. The header attribute within the <TD> tag of all other cells is used to associate the cell with its corresponding row and column headers.
The second option is to use the scope attribute. The scope attribute associates a set of <TD> tags with the corresponding <TH> tag. The scope attribute within the <TH> tag is used in the first cell of each column to define the column header. The scope attribute within the <TD> tag is used in the first cell of each row to define the row header.
Exhibit 6-7.2.1 (p. 1)
Example of a Simple Table (Using the header and id Attributes)
The code for this table immediately follows the screen shot. Figure A. Screen shot for a simple table that uses the header and id attributes
Figure B. HTML code for Figure A.
<table width = 66% border = 1 summary = "This table summarizes the rates
for Priority Mail Global Guaranteed postage rates."> |
Exhibit 6-7.2.1b
Example of a Simple Table (Using the scope Attribute)
The following graphic is a screen shot of a simple table that uses the scope attribute. The code for this table immediately follows the screen shot. Figure A. Screen shot of a simple table that uses the scope attribute
Figure B. HTML code for Figure A
<table summary="The Postal Bus Schedule" border="1"> |
When a data table has more than one logical level of row or column headers, it is a complex table. The axis attribute is used to create categories in a complex table.
The table used in the following example lists travel expenses at two locations (San Jose and Seattle) by date and category (meals, hotels, and transport).
The caption centered above the table reads, "Travel Expense Report."
The axis attributes or categories of the table are as follows:
• City.
• Travel dates.
• Meal expenses.
• Hotel expenses.
• Transport expenses.
The first row of the table contains these headers: "Meals," "Hotels," "Transport," and "Subtotals." The first row group shows the expenses in San Jose for those categories on August 25-26, 1997. Below that row group, the subtotals of all expenses in San Jose are listed.
The second row group presents similar data for expenses incurred in Seattle on August 27-28, 1997. Below that row, subtotals of all expenses in Seattle are listed.
The final row of the table lists the combined total expenses for San Jose and Seattle for "Meals," "Hotels," and "Transport." It also provides the total of all money expensed on the entire report.
Exhibit 6-7.2.2b (p. 1)
Example of a Complex Table Using the axis Attribute
The following is a screen shot of a complex table. The code for the complex table immediately follows the screen shot and shows how to create categories using the axis attribute. Figure A. Screen shot of complex table using the axis attribute
Figure B. HTML code for Figure A
<table border ="1" summary = "This table summarizes travel expenses
incurred during August trips to San Jose and Seattle"> |
Exhibit 6-7.2.2c
Example of a Complex Table
Figure C. Complex table The following is an example of a complex table. This example does not have HTML code provided but instead illustrates how tables can have multiple headings. 
|
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• For data tables, ensure that all of the relevant data, row headers, and column headers have been properly tagged and can be interpreted correctly.
• For data tables, test the tables with JAWS to ensure that they read logically left to right and top to bottom and that the content reads in the same order as intended by the author.
• Ensure that layout tables contain proper summary attributes or <CAPTION> tags (e.g.,"this table is for layout only").
The following references are provided for more information on this topic but must not be used in place of the Postal Service guidelines given above. If these references conflict with the above techniques, you must defer to the Postal Service guidelines.
• Identify row and column headers
http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables
• Postal Service accessible tables FAQs
http://cto.usps.gov/pls/itprodnp/page?psite_id=10&pnode_id=305
Framesets must be constructed so that the user does not have to depend on visual cues to navigate the site. Frames must be titled with text that facilitates frame identification and navigation (Section 508, Provision §1194.22i).
Frames must be titled so that screen reader software can identify the frame content to the visually impaired. Untitled frames make it difficult for the visually impaired to navigate the Web content.
Descriptive titles allow assistive technology (such as screen reader software) to identify the frame content to end users.
Organize the presentation of your Web pages so that the use of frames is minimal or not required.
Consider that users may not be able to link or create bookmarks to frame content. A bookmark or forwarded link would show the initial frameset and not the information the user wants to reference. Additional problems include effectively disabling the `back' button on users browsers, disabling printing of content (only one of the frames prints), lack of indexing by search engines, and frames can be inaccessible to users of screen magnification software and some hand-held devices.
Provide meaningful title attributes for each <FRAMESET> and <FRAME> tag. The titles must describe the content of the frame page and individual frame.
HTML Code for Frames
Use Valid HTML 4.01 Frameset DTD. HTML 4.01 specifies three document
type definition (DTDs) with one specifically for Framesets. Authors must
include the following document type declarations in their frame documents:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Ensure that there is a meaningful page title for HTML pages that contain the <FRAMESET> tag.
• Ensure that every <FRAMESET> tag has a meaningful title.
• Ensure that every <FRAME> tag has a meaningful title.
• Test the non-frame version or alternative format provided to verify that it has the same functionality.
The following references are provided for more information on this topic but must not be used in place of the Postal Service guidelines given above. If these references conflict with the above techniques, you must defer to the Postal guidelines.
• Frame title
http://www.w3.org/TR/WCAG10-HTML-TECHS/#frame-names
• Postal Service accessible frames FAQs
http://blue.usps.gov/508web/FramesHelp.html
• Alternatives to frames
http://www.w3.org/TR/WCAG10-HTML-TECHS/#alt-frames
• HTML version information (including frameset DTDs)
http://www.w3.org/TR/html4/struct/global.html#version-info
Web pages must not use flashing or blinking text, objects, or other elements having a flash or blink frequency between 2 and 55 cycles per second (2.0 Hz and 55.0 Hz). If flashing is present, provide a way to change the frequency (Section 508, Provision §1194.22j).
Screen items that flash or blink can cause seizures or other involuntary responses, particularly if they flash in high intensity, with high contrast, and in the frequency range between 2 and 55 cycles per second (2.0 Hz and 55.0 Hz).
Web applications must not use flash or blink rates in the range stated above. This includes, but is not limited to, flashing text, rapid screen rewrites, images that cycle on and off, and repeatedly changing or animated user interface elements. If software uses flashing or blinking user interface elements, a feature that allows the user to change their frequency or disable the function must be provided.
Provide graphics that do not flash or blink in the frequency range between 2.0 Hz and 55.0 cycles per second (between 2 Hz and 55 Hz).
When Web applications do provide flashing elements such as animated images, development techniques must be used to allow the user to control certain aspects of the flashing element's flash or blink rate (to alleviate the risk of producing adverse physical affects). These development techniques include the following:
a. Providing the user with the ability to adjust the flash speed (see exhibit 6-9.2).
b. Minimizing the area of the screen that is flashing (smaller areas are less likely to cause seizures).
c. Avoiding flashing that has a high level of contrast between light and dark, such as light colors and dark colors (some individuals are more susceptible to high-intensity flashing).
d. Providing a feature that will completely disable the flashing or animation.
Exhibit 6-9.2
Dialog Box Controlling Frame Rate of Animation
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Ensure that a display that flickers or flashes is not within the frequency range of 2 to 55 cycles per second (2Hz to 55Hz) and that there are no quick changes from dark to light (like to strobe lights).
• Ensure that page content is not affected if animations are disabled.
The following reference is provided for more information on this topic but must not be used in place of the Postal Service guidelines given above. If these references conflict with the above techniques, you must defer to the Postal Service guidelines.
• Avoiding flicker
http://www.w3.org/TR/WCAG10-TECHS/#tech-avoid-flicker
• Effective color contrast
http://www.lighthouse.org/color_contrast.htm
When compliance cannot be achieved, provide an alternate format or alternate access method that will be used in addition to, or in place of, the primary Web page, site, application, information, links, or data (Section 508, Provision §1194.22k).
Alternate formats or access methods are intended to be equivalent to the primary Web source in both content and functionality and must be updated concurrently with the primary Web source.
URL hyperlinks or text links such as "click here" do not clearly indicate the destination or purpose of the link. Descriptive text links enable assistive technology to provide information that describes the destination or purpose of the link.
Create your original Web application, information, links, and data in a standard, accessible format so that text-only or alternate formats are not needed.
When updates to the primary content are made, ensure that the text-equivalent or alternate formats are updated concurrently.
When converting documents created by office suites into HTML for compliance, table headers and image alt attribute tags are required. When converting such documents into plain text formats for the Web, data tables must be converted so that the text data is equivalent to the original data table.
Exhibit 6-10.2.1
Example of a Microsoft Word® Table
Figure A. Microsoft Word® table
|
Automatically generated HTML, such as created by Microsoft Word's File, "Save As Web Page" option, must comply with the other requirements for HTML in this chapter. HTML content generated by this method is frequently not valid HTML and should be checked by using a web page validation tool such as that provided by the W3C® MarkUp Validation Service.
Viewing the generated HTML in a Web browser is not a sufficient test of valid HTML. Frequently, Web browsers ignore defects in coding in order to provide a better end-user experience. The invalid HTML or defects may interfere with assistive technology, may not render properly, or may not render any of the intended information.
Descriptive text links must state more than "click here." However, they must not be so wordy that they interfere with efficient browsing. Nondescriptive URL hyperlinks, such as "click here" convey little meaning to the visually impaired andmust not be used. The display of a URL must be accompanied by the corresponding descriptive text link.
Note: Examples from this document's reference sections illustrate proper use of a descriptive link.
Exhibit 6-10.2.2a
Example of the Proper Use of a Descriptive Link
Go to USPS Home Page (http://www.usps.com) |
Exhibit 6-10.2.2b
Example of Link Images
Use the alt attribute to provide a descriptive text equivalent for an image that is used as a link.
width="50" height="15" src="/common/images/style2_7/search_home.gif" type="image" value="Search" name="search" tabindex="2"> |
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• When converting office suite documents into HTML, table headers and image alt attribute tags are required.
• Verify that the content of the alternate format or alternate access method is equivalent to both the content and functionality of the primary Web content.
• Update the alternate format content concurrently with the primary Web content. Ensure that no information has been lost and that the meaning remains the same.
When pages use scripting languages to display content or to create interface elements, the script must provide meaningful text that can be read by assistive technology. If an accurate message cannot be conveyed by the results of the script, provide an equivalent alternate format or access method (Section 508, Provision §1194.22l).
Assistive technologies may not support some scripting languages. Scripting must follow Web standards; otherwise, a screen reader could read the content of the script as a meaningless mixture of numbers and letters.
Some browsers are unable to run scripts, and some users' browsers are configured not to run any scripts.
Web content must be accessible when the scripting is unavailable. The design of Web content should be secondary to being able to access that content.
Scripts must not interfere with assistive technology. Scripts frequently are used to change information and user focus. Test your scripts with accessible technology to ensure that your scripts do not create content that is inaccessible.
If the results of a script cannot be accessed by assistive technology or if a meaningful message cannot be conveyed with the use of assistive technology, provide an alternate format or access method.
Use the <NOSCRIPT> tag to provide content to browsers that cannot run scripts.
Do not use redirects or scripts in place of Uniform Resource Locators (URLs). Scripts that directly call functions (e.g., <a href="javascript:DoSome Function()">) must use a URL (e.g., <a href="http://www.usps.com/Do SomeFunction()>).
Provide accessible URLs if you use scripts functions in links (e.g., <a href=http://www.usps.com/ on Click="javascript(DoSomeFunction)">).
Warn if scripts are changing focus, such as opening a link in a new window.
Browser detection routines must not require a specific browser client. Browser detection routines should always allow the user the option to view the Web content. Assistive technology and alternative Web browsers may meet the technical requirements to view your Web content but may not be allowed to view that content by a poorly written or defective browser detection routine.
When recommending use of specific browsers, design your scripts to allow users to continue accessing the Web content even if they are not using the recommended browser.
Using the commonly used standards and recommendations, such as those created by the W3C, is always preferred.
When creating scripts that detect specific browser versions, ensure that you only identify user agent strings or browsers that you know do not function with the content of your Web page. Do not require a specific browser for viewing the Web content.
The alternative format or access method must be used in addition to, or in place of, the primary Web content. The alternate format must be equivalent to the primary Web source in both content and functionality and must be updated concurrently with the primary Web source.
Scripts that dynamically generate content that cannot be conveyed by assistive technology must have an equivalent alternate format or access method that can be read by assistive technology. This is an issue primarily in client-side scripting. For example, a script could dynamically generate drop-down menus with hypertext links. The script must follow the accessibility requirements to create descriptive text links, using the <TITLE> attribute of the <a href> tag. Do not use scripting to create graphics and menus that are inaccessible. All scripts must follow the other requirements in this chapter.
Accessibility-enabled Java applications are not dependent on machines that require assistive technology support. These applications will run on any Java platform, with or without assistive technologies. However, to provide access to Java applications, assistive technology requires more than the Java Accessibility API.
Sun's Java Accessibility Utilities help assistive technologies interact with applications developed using the Java Accessibility Application Program Interface (API). An application developer can use these APIs directly or indirectly using the Swing toolkit. Developers can create Java applications capable of interacting with assistive technologies such as screen readers, speech recognition systems, and Braille terminals.
Ensure that the version number of the Java Accessibility Utilities matches the version number of the Java Platform. For example, Java Accessibility Utilities v. 1.3 should be used if Java 2 Platform, Standard Edition v. 1.3 (JDK 1.3) is the version installed on the system where the evaluation is occurring.
Although accessibility support became available in SDK/JDK 1.1.x, it is best to use the Swing user interface development kit that is included in SDK 1.3 or higher. This will provide the highest level of accessibility functions.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Test with Assistive Technology (AT) to ensure that all content from scripts, applets, or plug-ins is accessible.
• Use the most recent version screen reader with the Java Access Bridge and the Java plug-in to test Java applications for accessibility. Developers can ensure that the environment is set up appropriately by using the quick check utilities available from Sun.
• Verify that the content of the alternate format or alternate access method is equivalent to the content and functionality of the primary Web source and that it is updated concurrently with the primary Web source. Ensure that no information has been lost and that the meaning has remained the same.
The following references are provided for more information on this topic but must not be used in place of the Postal Service guidelines given above. If these references are in conflict with the above techniques, you must defer to the Postal Service guidelines.
• Java Accessibility
http://www-3.ibm.com/able/accessjava.html
• Writing accessible Java applications
http://www-106.ibm.com/developerworks/java/library/j-access/
• Sun's JAVA accessibility utilities
http://www.sun.com/access/downloads/#sun
• Java Developer's Forum
http://developer.java.sun.com/developer/community/chat/index.html
• Trace Center examples of accessible Java
http://www.trace.wisc.edu/world/java/java.htm
Provide a link to a plug-in or applet that complies with the Access Board's standard, 36 CFR 1194.21 (Software Applications and Operating Systems), if a Web page requires an applet, plug-in, or other application to be present on the client system to interpret page content.
If the results of an applet or plug-in cannot be accessed by the assistive technology or if a meaningful message cannot be conveyed through the results of assistive technology, provide an alternate format or access method (Section 508, Provision §1194.22m).
Web browsers may not have specific plug-ins necessary to view the content format. Users needing to install a plug-in may not have the file permissions needed to complete the installation of the required plug-in.
Plug-ins that provide information that is not essential to the understanding or navigation of the Web content can still be used and do not need an equivalent alternate format or access method.
Provide enough information directly in the Web content or in attribute tags to indicate that the information is not essential.
Use the alt attribute to provide a text description for applets.
Create a hyperlink to information for downloading the correct plug-in next to the object that requires a plug-in.
Exhibit 6-12.2
Example of an Applet
<applet code = "gravity.class" width ="200" height = "250" alt="Java gravity
applet"> ...
</applet> |
If a plug-in, applet, or other application is necessary to access the Web content, provide a hyperlink to the plug-in. The plug-in must comply with the Access Board's standard, 36 CFR 1194.21 (Software Applications and Operating Systems).
If the plug-in is not accessible, provide an alternate format or alternate access method to the content.
Note: Plugins for PDF formats are covered in Section 6-13, Forms.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following step:
Ensure that the applet or plug-in is compliant with the Access Board's standard, 36 CFR 1194.21 (Software applications and Operating Systems).
The following references are provided for more information on this topic but must not be used in place of the Postal Service guidelines above. If these references are in conflict with the above techniques, you must defer to the Postal Service guidelines.
• HTML Techniques for Web Content Accessibility
http://www.w3.org/TR/WCAG10-TECHS/#tech-scripts
When electronic forms are designed to be completed online, the form must allow access via assistive technologies to information, field elements, and functionality, (e.g., associated controls required to complete, review, revise, and submit the form, including directions and cues) (Section 508, Provision §1194.22n).
Screen readers may have difficulty navigating through interactive forms without the required modification to the form.
Forms may require a timed response (e.g., security functions). Assistive technologies may prevent users from completing online forms within the required time limit.
Construct electronic forms (for completion online) so that assistive technologies (such as screen readers) can relay the relevant field descriptors when tabbing from field to field. Use logical tabbing order consistently throughout the form.
The assistive technology must be able to edit fields and allow users to read back and/or revise information previously entered into a field.
When a timed response is required, users must be alerted and given sufficient time to indicate that they need additional time to complete the form. (Refer to Section 6-16, Timed Reponses).
A <LABEL> tag must identify all form controls, except for form controls that automatically have text descriptions associated with them, such as submit buttons. The <LABEL> tag must appear either immediately to the left or right or immediately above the field. Image buttons also need descriptive text associated with the form control. For forms that are laid out inside <TABLE> tags, the <LABEL> tag must appear in the same table cell as the form control.
An implicit label is a label that surrounds a form control with a <LABEL> tag. An explicit label uses the <LABEL> tag with the associated for attribute and with the equivalent id attribute in the form control. Explicit labeling techniques must be used, because implicit labels are not supported universally by screen readers. In addition, users will have difficulty interpreting the form if any text separates implicit labels from associated form controls.
Exhibit 6-13.2a
Example of a Text Box and Buttons
Figure A. Screen shot of a form with text boxes and buttons
Figure B. Relevant HTML code for Figure A <form method=post action="/cgi-bin/cgi.pl"><p> <label for ="Name">Name:</label> <input tabindex="1" type="text" id="Name" name="Name" size=30 maxlength =75><br> <label for ="Address">Address:</label> <input tabindex = 2 type = text name = Address id=Address size =50 maxlength = 75> </p> <p> <Iinput tabindex = 3 type = submit name = SubmitButton value = Submit Query> <input tabindex = 4 type = reset name = ResetButton value = "Reset"> </p> </form> |
Exhibit 6-13.2b
Example of a Text Area Box
Figure A. Screen shot of a text area box
Figure B. Relevant HTML code for Figure A <form name=text box method=post action=test.cfm><label for=motives>Explain how your web content adheres to the Section 508 Standards:</label> <p><textarea id=motives name=motives tabindex=1></textarea> </p></form> |
Exhibit 6-13.2c
Example of a Select Box
Figure A. Screen shot of a select box
Figure B. Relevant HTML code for Figure A
<label for=IfavstampI>What is your favorite stamp?</label> |
Exhibit 6-13.2d
Example of a Check Box
Figure A. Screen shot of check boxes
Figure B. Relevant HTML code for Figure A <form name=form1 method=post action=checkbox.cfm>Choose a Stamp:<br> <input id=bison type=checkbox name=checkbox value=checkbox tabindex=1> <label for=bison>Bison</label><br> <input id=fox type=checkbox name=checkbox2 value=checkbox tabindex=2> <label for=fox>Red Fox</label><br> <input id=eagle type=checkbox name=checkbox3 value=checkbox tabindex=3> <labelfor=eagle>Eagle</label> </form> |
Exhibit 6-13.2e
Example of Radio Buttons
Figure A. Screen shot of radio buttons
Figure B. Relevant HTML code for Figure A
<form name=form2 method=post action=radiobutton.cfm> |
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
a. Test all forms for accessibility using JAWS. The form must be tested in both the forms mode and the Virtual PC cursor mode. The forms mode ensures that fields can be edited. The Virtual PC cursor mode ensures that responses can be read back or changed by the user.
b. Verify that <LABEL> tags, text descriptions, tabbing order, and the like, read correctly.
c. Verify that the user can ask for additional time to complete a form when timed responses are required.
The following reference is provided for more information on this topic but must not be used in place of the Postal Service guidelines given above. If these references conflict with the above techniques, you must defer to the Postal Service guidelines.
• USPS accessible forms FAQs
http://blue.usps.gov/508web/FormsHelp.html
On Postal Service Internet and Intranet sites, all portable document format (PDF) files must have an additional alternate accessible format posted for use by the public and employees.
PDF files may be completely or partially inaccessible to a screen reader or may be read in an illogical order by a screen reader. Posting an alternate format or access method along with the PDF is the only way to ensure accessibility.
An accessible PDF file uses tags to make the content of a character-based document available to a screen reader. Tags define the logical structure of the character-based document such as titles, headings, paragraphs, tables, etc. The underlying process of tagging a PDF file is similar to tagging an HTML or XML file. Original source files must be accessible before the conversion process begins, or the resulting PDF will likely be inaccessible.
The accessible tagged PDF file must be used with the accessible version of Adobe Acrobat Reader and a Microsoft Active Accessibility (MSAA) compliant screen reader such as JAWS.
There are four basic steps to generating accessible tagged PDF files:
a. A document's origin may be an original source file, a PDF file (character-based or image-based), or a paper document. Each of these requires different procedures. However, all of the procedures will result in a character-based PDF file.
b. The second part of the process is to generate the initial tags (automatically or manually) for a character-based PDF file.
c. The third part of the process is to fine-tune the tags for access by a MSAA-compliant screen reader and adherence to Postal Service Section 508 Web Accessibility Guidelines.
d. The final step in the process is to determine accessibility and compliance by testing the tagged PDF file, using the most recent version of JAWS and the accessible version of Adobe Acrobat Reader.
To be an accessible and fully compliant tagged PDF file, the contents must be read in the logical order intended by the author, must be accessible to the MSAA compliant screen reader, and must adhere to the Postal Service Section 508 Web Accessibility Guidelines.
Since the MSAA compliant screen reader is required, accessible tagged PDF files can be tested only in the Windows environment. Unlike other PDFs, the accessible tagged PDF is not universally available to screen readers across all platforms. Therefore, an accessible and fully compliant version of a tagged PDF file must still have an alternate format or alternate access method posted on the Intranet and the Internet.
Provide an alternate format or access method that will be used in addition to, or in place of, the PDF file. Alternate formats or access methods must have equivalent content and functionality to the primary Web source and must be updated concurrently with the primary Web source. The Postal Bulletin is an example of providing alternate format in both .pdf and .html. (http://www.usps.com/cpim/ftp/bulletin/pb2004.htm).
For internal and external Postal Service Web content, that alternate format may be an HTML, plain text, or rich text format (RTF) file. For internal sites only, the alternate format may also be one of the native formats used by the Postal Service for its standard suite of office products (i.e., Microsoft Word®, Excel®, and PowerPoint®). Since files provided externally must be presented in alternate formats available to non-Microsoft platforms, standardizing on the non-Microsoft alternate formats (plain text (.txt) or rich-text format (.rtf) instead of MS Word (.doc) files, comma separated values (.csv) instead of MS Excel (.xls) files, hyper-text markup language (.html) instead of MS PowerPoint) is preferred.
In considering the options suggested above, keep in mind the extent of the conversion and review efforts, the resources required to maintain separate Web content, the size of the alternate file format and the time that it will take to load or download the file, the availability of a source file, and the relevance of existing PDF files. The conversion of PDF files requires extensive review, comparison, and validation.
Print-only PDF Forms that are available for download must have an associated text description that describes the form along with its number, title, and purpose.
Remember to provide a link to the acrobat reader or plug-in.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Use the most recent version of JAWS, in conjunction with the accessible version of Adobe Acrobat reader, to test the tagged PDF file to determine whether the contents are in the logical read order intended by the author, all information and links are accessible by JAWS, and whether the file adheres to all other guidelines in this document.
• If additional revisions are needed, fine-tune the tags and test again until the tagged PDF file is both accessible with JAWS and compliant with the Postal Service Section 508 Web Accessibility Guidelines.
• Verify that the content of the alternate format or access method is equivalent with the content and functionality of the primary PDF file and is updated concurrently with the primary Web source. Ensure that no information has been lost and that the meaning has remained the same.
For more information on this topic, please check the following links:
• Adobe PDF accessibility information
http://access.adobe.com/information.html
• How to Create Accessible PDFs
http://access.adobe.com/booklet1.html
• Handbook AS-885, usps.com Development Process and Standards,
Chapter 5, Section 5.5, File Formats
http://blue.usps.gov/cpim/ftp/hand/as885/
• WebAIM Microsoft Word Accessibility Techniques
http://webaim.org/techniques/word/
• WebAIM Adobe Acrobat Accessibility Techniques
http://webaim.org/techniques/acrobat/
Provide a method that will permit users of assistive technology the option to skip repetitive navigation links (Section 508, Provision §1194.22o).
Insert a link that will allow the users to skip repetitive navigation links. It is common for Web authors to place navigation links at the top, bottom, or side of every new Web page. This technique can render the use of web content very difficult for persons using a screen reader because screen readers move through pages reading from top to bottom. The use of repetitive navigation links and URL links forces persons with visual impairments to re-read these links when moving to every new page.
Descriptive text links should make sense when read out of context (such as in a HTML bookmark list) by the screen reader.
Insert a descriptive text link that will allow a user to skip the repetitive navigation links.
To facilitate easy tracking of page content, insert a descriptive text link before a repetitive navigation link, so that users will be able to go directly to the main content of the page.
This link may either be displayed to all users or be transparent so that it can be read only by a screen reader. To make a link transparent, use either a 1-pixel GIF that is the same color as the background or the hyperlink. The 1-pixel GIF can also be a transparent GIF. This GIF file must also have an alt attribute that states "Skip navigation" or a hyperlink that is the same color as the background that contains the text "Skip navigation" between the <A href> tag and the </A> tag. The user must be taken to the main content of the page.
Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In your testing, perform the following steps, as applicable:
• Examine all repetitive navigation links. Ensure that you insert a descriptive text link that will allow a user to skip the repetitive navigation links. Check the link to make sure that it takes the user directly to the main content of that Web page.
• Examine links apart from the body of the document. Make sure that descriptive text still makes sense when read out of context by the screen reader.
When a timed response is required, users must be alerted and given both a mechanism and sufficient time to indicate that they need additional time (Section 508, Provision §1194.22p).
A disability can have a direct affect on the speed with which a person can read and move around Web content. The Web page session may expire, which can, in turn, cause an automatic refresh, an update of screen content, a redirection to another resource, a termination of a secure session, a disconnection, or a standby status, if a response is not received within a specified time.
Refreshing or redirecting the user to new Web content can confuse and make it difficult for users of assistive technology.
If the business or security requirement is that an application should timeout after a fixed period of inactivity, alert the user when a timeout is about to occur. Give the user ample opportunity to answer a prompt asking if the user needs more time.
Exhibit 6-15.2.1
Web Session Timeout Warning Dialog
|
Figure A. The alert that warns users of an impending timeout in the Click-N-ShipTM application |
Repeat the process until the user indicates that additional time is not required. If the user does not respond or indicates that no more time is needed, the timeout can take place.
If the business or security requirement is that a timed feature in a Web application is only for a fixed session or time limit (combined activity or inactivity), then the user must be notified at the start of the session that the session will timeout after a fixed amount of time. Before the fixed time limit, an alert must communicate the impending timeout to the user. Then the user can be timed out at the appointed time. In such cases, a longer fixed session for persons with disabilities is not necessary.
The specific time that is appropriate from when the timeout message is given, to the point when the timeout takes place varies by the complexity of the application.
Once a timeout has been reached, Web content must not be automatically updated or refreshed unless the update is based on a user selection or the user is notified a refresh is going to occur. An example of a user selection would be resetting of a Web application to an initial login page after the user selects "OK" on a timed logout notice.
Use the refresh meta-tag only when the user has requested auto-refresh. Notify the user of any changes resulting in a redirect. Most redirects are done without the user's control. Web content developers should update content to reflect changes in hypertext links and notify users when it is known that redirects will occur.
An example of HTML code for an automatic refresh is given below:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">Manual testing, using the testing methods described in this chapter, is mandatory, because it simulates use by assistive technology users. Automated testing tools and methods can help automate these methods, but automated testing must be accompanied by manual testing. In testing, perform the following steps, as applicable:
• Ensure that if given the option, any timeouts will allow a user to indicate that additional time is required.
• Ensure that timeouts notify the user that a timeout has occurred and the reason for the timeout. This includes notifying the user a redirect is going to occur.
• Ensure users are asked if they wish to have auto-refresh of content enabled. Default to not using auto-refresh.
• Ensure that users are notified of fixed time limits before they begin.
Appendix 6-A
Web-Based Information and Applications
Accessibility Checklist
Use this as a tool for determining if a Web-based application or information is compliant or accessible.
| Requirement Number and Summary | Yes, No, or N/A | Comments | |
| 6-2 | Non-Text Elements. A descriptive text equivalent must be provided for all non-text elements that render information required for comprehension of the content, as well as those that facilitate navigation. Non-text items include images, video, graphs, charts, animation, and audio (Section 508, Provision §1194.22a). | blank | blank |
| 6-3 | Multimedia. Provide equivalent alternate formats or alternate access methods for any multimedia presentation and synchronize them with the presentation (Section 508, Provision §1194.22b). | blank | blank |
| 6-4 | Color. Web pages must be designed so that all information required for navigation or meaning is independent of the ability to identify specific colors (Section 508, Provision §1194.22c). | blank | blank |
| 6-5 | Style Sheets. Documents must be organized so that they are readable without an associated style sheet. Documents must be constructed so that the user does not need style sheets to interpret the content of the Web page. This does not prohibit the use of style sheets (Section 508, Provision §1194.22d). | blank | blank |
| 6-6 | Image Maps. Use client-side image maps, whenever possible, in place of server-side image maps (Section 508, Provision §1194.22e). Provide equivalent redundant text links for all server-side image map hot-spot areas (Section 508, Provision §1194.22f). | blank | blank |
| 6-7 | Tables. Tables must be constructed so that they can be easily interpreted by all users and communicate the intent of the author (Section 508, Provision §11 | ||
