The file's text, extracted by GovTribe without its formatting.
Applicable Provisions and Testing
Complete this document in stages, beginning with the selection of applicable requirements during Readiness and updated during Execution. When using JAWS with this document, down and up arrows work better than tab and shift-tab for reading multi-line content. Add Project Information: Project Name, Project Acronym, Project Phase, and Project Description (focus on user interfaces). When submitting for review, update Change Date and Change Notes to let reviewers know what to review.
For each Requirement:
· Requirement Text (leave in place)
· Applies? Check checkbox to indicate that the requirement applies; uncheck checkbox if the requirement does not apply.
· Test Plan For each applicable requirement, state how the project will test.
· Date Tested Enter date when testing occurred or when non-applicability was determined.
· Test Results For each applicable requirement, explain what the project found in testing or, if indicating non-applicability, state reason.
· Conforms? For each applicable requirement, check checkbox if testing shows that the requirement is met. Uncheck checkbox if testing shows that the requirement is not met.
· Mitigation - If requirement applies but is not met, explain how affected users can work around the issues.
· Feedback - Space for reviewer to provide feedback to the project.
The 508 requirements are grouped in the following order: 1. WCAG 2.0 Level A and AA Success Criteria; 2. Functional Performance Criteria; 3. Support Documentation and Services; 4. Hardware; 5. Software; 6. Referenced Standards. Appendices: 7. Crosswalk from Original to Revised Standards and 8. 508 Testing Tools.
Project Information
1. WCAG 2.0 Level A and AA Success Criteria
| 1.1.1 Non-text Content |
| All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. |
| Test Plan |
| Show that images have text alternatives that are equivalent to meaning provided by the images. Check that JAWS announces text indicating the function or purpose of the images when they receive focus. Verify that the accessible name or alt attribute value of a decorative image is blank or null, or a decorative image has been effectively hidden from assistive technologies. Verify that JAWS ignores decorative images. |
| 1.2.1 Audio-only and Video-only (Pre-recorded) |
| Audio-only and Video-only (Pre-recorded) - For prerecorded audio-only or video-only media, an alternative provides equivalent information. |
| Test Plan |
| For audio-only content, compare the transcript text to the audio. For video-only content, check that the description is available as screen text or as an audio file. Verify transcripts of video presented as on-screen text can be read with JAWS. |
| 1.2.2 Captions (Pre-recorded) |
| Captions are provided for all prerecorded audio content in synchronized media. |
| Test Plan |
| Where there is video, show that captions are synchronous and accurate. |
| 1.2.3 Audio Description or Media Alternative (Pre-recorded) |
| 1.2.3 Audio An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media.or Media Alternative (Pre-recorded) |
| Test Plan |
| Verify video description has been provided for key visual elements and any on-screen text that is synchronized with the video. |
| 1.2.4 Captions (Live) |
| Captions are provided for all live audio content in synchronized media. |
| Test Plan |
| Where there is video, show that captions are synchronous and accurate. |
| 1.2.5 Audio Description (Pre-recorded) |
| Audio description is provided for all prerecorded video content in synchronized media. |
| Test Plan |
| Verify audio description has been provided for key visual elements and any on-screen text that is synchronized with the video. |
| 1.3.1 Info and Relationships |
| Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. |
| Test Plan |
| Show that web data tables are formed with table tags beginning with table and also that the row and column header cells are formed with th scope="col" for the column headers and th scope="row" for the row headers or that row and column headers are connected to data cells with headers and ids. Verify data presented in tabular format is presented within correct table structures, and table headers have been properly identified, and correct associations have been made between table headers and data cells. |
| 1.3.2 Meaningful Sequence |
| When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. |
| Test Plan |
| Check that content is presented in the same reading order with CSS enabled as it is with CSS disabled. Disable CSS in Internet Explorer - View - Style - No Style. For Microsoft Edge open the dev console with f12, then click the console tab on the bottom, then input "$('style,link[rel="stylesheet"]').remove()" (without quotes) into the console and press enter to remove CSS. |
| 1.3.3 Sensory Characteristics |
| Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. |
| Test Plan |
| Verify that instructions do not require users to possess specific sensory characteristics to be executed, or redundant instructions have been provided that do not make use of the sensory characteristic. |
| 1.4.1 Use of Color |
| Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. |
| Test Plan |
| Verify that any uses of color to convey meaning, indicate an action, prompt a response or distinguish a visual element are coupled with redundant alternatives that do not use color to convey the same information. Ensure any information that is conveyed using color is also available through use of JAWS. |
| 1.4.2 Audio Control |
| If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. |
| Test Plan |
| Check that audio that automatically plays for more than three seconds can be paused or turned down independent of the system volume. |
| 1.4.3 Contrast (Minimum) |
| The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, with a 3:1 ratio for large-scale text. |
| Test Plan |
| Use a color contrast analyzer tool to inspect the ratio between text and images of text and background colors. |
| 1.4.4 Resize Text |
| Text can be resized without assistive technology up to 200 percent without loss of content or functionality. |
| Test Plan |
| Ensure that the text size can be increased up to 200 percent without ZoomText. |
| 1.4.5 Images of Text |
| If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text. |
| Test Plan |
| If there are images of text, discern if the format of image of text is essential for branding, such as for a logo. |
| 2.1.1 Keyboard |
| All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. |
| Test Plan |
| Keyboard Access: Use standard keyboard commands to show navigation and functionality. Identify interactive interface elements using the mouse, then show how those elements can be accessed and activated with keyboard alone. Use standard JAWS keyboard commands to access and activate functions. Use ZoomText with keyboard to access and activate functions. Test all keyboard functionality with keyboard commands spoken to Dragon. |
Hover: Show how content that is exposed by hovering the mouse can be exposed using the keyboard alone. Show that information and controls that appear on mouse hovers are spoken using standard JAWS keyboard commands. Confirm keyboard equivalents with ZoomText running for all mouse hover functions. Confirm voice equivalents using Dragon for all mouse hover functions.
Non-Standard: Descriptions of custom keystrokes are available to users where the keystrokes are needed and perform the documented action. Non-standard JAWS keyboard commands are announced by JAWS and perform the documented action. Custom keystrokes are available, and shortcuts perform the documented action with ZoomText running. Non-standard keyboard access is presented and functions for users of Dragon.
Context Menus: Context menus, menus that appear upon user interaction such as right clicking, can be invoked from the keyboard. Context menus can be invoked from the keyboard using standard JAWS keyboard commands. Context menus can be invoked from the keyboard using ZoomText. Context menus can be invoked using Dragon.
Drag-and-Drop: Drag-and-drop functions can be performed solely using the keyboard. Drag-and-drop functions can be performed with JAWS using application keystrokes for drag-and-drop. Drag-and-drop functions can be performed with Dragon by speaking application keystrokes for drag and drop.
| 2.1.2 No Keyboard Trap |
| If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. |
| Test Plan |
| Move keyboard focus away from elements with no assistive technology running, with JAWS, with ZoomText, and with Dragon. |
| 2.2.1 Timing Adjustable |
| For each time limit that is set by the content, the user can turn off, adjust, or extend the limit. |
| Test Plan |
| Learn if the user is warned before their session expires. Verify that JAWS announces any time-out warnings or focus is set to the warning. With ZoomText, ensure any time-out warnings are displayed in the magnified area of the screen. Measure if the user is given at least 20 seconds to respond to a time-out alert. Using Dragon, verify that users can extend their session using voice control. Learn if the user is given the option to extend their session before the request times out. |
| 2.2.2 Pause, Stop, Hide |
| For moving, blinking, scrolling, or auto-updating information, the user can pause, stop, hide, or adjust the information. |
| Test Plan |
| Check if a keyboard accessible and focusable mechanism exists to pause, stop or hide moving, blinking or auto-updating content that lasts for more than 5 seconds. |
| 2.3.1 Three Flashes or Below |
| Content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. |
| Test Plan |
| If there is flashing on the page, show that it does not flash more than 3 times per second (unless it is so fast it cannot be seen flashing). |
| 2.4.1 Bypass Blocks |
| A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. |
| Test Plan |
| Check if a mechanism to skip content that is repeated across pages can be triggered from the keyboard which moves focus to the unique page content. Verify that a mechanism to skip past content repeated across pages can be triggered from the keyboard which causes JAWS to read at the point where the unique page content begins. Using ZoomText, verify that a mechanism to skip content repeated across pages is implemented which scrolls the unique page content into the magnified region of the screen. Using Dragon, learn if a mechanism to skip past content repeated across pages can be triggered using voice commands. |
| 2.4.2 Page Titled |
| Web pages, non-web documents, and software have titles that describe topic or purpose. |
| Test Plan |
| Show that the pages or screens have meaningful titles. Show the Title that shows at the top of the window or the Title tag in HTML. Learn if JAWS announces the title of the application or web page. Verify that a title attribute is provided for each frame or iframe element that is not hidden from assistive technologies with a meaningful value indicating the topic or purpose of the content inside the frame. Ensure that JAWS announces an informative title for each frame and iframe and displays a meaningful title in the Frames List. |
| 2.4.3 Focus Order |
| If content can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. |
| Test Plan |
| As you are tabbing through interface elements, assess whether the tab order is logical. Using JAWS, verify the tab/navigation order of the interface follows the logical visual order of interactive elements. |
Verify focus moves inside a modal dialog when a modal dialog is opened and remains inside the dialog when navigating between components. Verify JAWS users are aware of the presence of modal dialogs and focus is set appropriately so that reading resumes within the dialog when it is invoked. Verify that a modal dialog appears within the magnified portion of the screen when it is opened with the keyboard with ZoomText running.
Verify focus returns to the triggering element or to a logical location after dismissing a component. Verify focus returns to the triggering element and resumes reading from this location with JAWS running. With ZoomText running, verify focus returns to the triggering element which appears in the magnified portion of the screen.
When hidden content is revealed (such as pop-ups and drop-downs) show that focus goes to that content. Verify JAWS users are alerted to the presence of newly revealed content. With ZoomText running, verify newly revealed content appears within the magnified portion of the screen.
| 2.4.5 Multiple Ways |
| More than one way is available to locate a Web page within a set of Web pages except where the Web page is the result of, or a step in, a process. |
| Test Plan |
| Check that each page has more than one way to get to it. Exception: pages that are presented as part of workflows, such as "thank you for completing the form." |
| 2.4.6 Headings and Labels |
| Headings and labels describe topic or purpose. |
| Test Plan |
| For the visually apparent headers on pages, make sure that they are formed with h1 through h6 tags, depending on hierarchy. Explain how Section headings describe their sections. |
Verify that labels describe the purposes of their associated form fields.
| 2.4.7 Focus Visible |
| Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. |
| Test Plan |
| Tab through interface elements to show that keyboard focus is visibly obvious as you go. |
| 3.1.1 Language of Page |
| The default human language of Web pages, non-Web documents, or software can be programmatically determined. |
| Test Plan |
| Check whether a lang attribute has been placed on the root element of the document with a language code matching the primary language used for content. Check if JAWS pronounces content using the language rules for the primary language in which content is written. |
| 3.1.2 Language of Parts |
| The human language of each passage or phrase in the content can be programmatically determined. |
| Test Plan |
| Verify that a lang attribute has been placed on any content written in a different language from the primary language used in the document with a language code matching the target language for content. Verify that JAWS temporarily switches to the language rules for the content in a different language than the primary language of the document and pronounces content using the language rules for the language in which content is written. |
| 3.2.1 On Focus |
| When any component receives focus, it does not initiate a change of context. |
| Test Plan |
| Verify any changes in state or value are indicated in text or programmatically as revealed by Edge's Inspect, Window's Inspect, or Java Ferret. Make sure changes of state and role are announced so that a user of JAWS is made aware of such changes. |
| 3.2.2 On Input |
| Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. |
| Test Plan |
| When hidden content is revealed (such as pop-ups and drop-downs) show that focus goes to that content. Verify JAWS users are alerted to the presence of newly revealed content. With ZoomText running, verify newly revealed content appears within the magnified portion of the screen. |
Verify any changes in state or value are indicated in text or programmatically as revealed by Edge's Inspect, Window's Inspect, or Java Ferret. Make sure changes of state and role are announced so that a user of JAWS is made aware of such changes.
| 3.2.3 Consistent Navigation |
| Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. |
| Test Plan |
| Verify that any set of links or other navigation mechanisms that repeat across web pages are presented in the same order on each page. |
| 3.2.4 Consistent Identification |
| Components that have the same functionality within a set of Web pages are identified consistently. |
| Test Plan |
| Confirm that the meaning represented by an image remains consistent across multiple uses of the same image. Using JAWS, check that the meaning represented by an image remains consistent across multiple uses of the same image. |
| 3.3.1 Error Identification |
| If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. |
| Test Plan |
| Make an error in the form and show how focus goes to an error message with enough information that users who make mistakes can recover from errors. Verify that JAWS announces error messages or sets focus to them and they are read by JAWS, and users of JAWS can identify, locate and recover from error conditions. Ensure error messages appear in the magnified portion of the screen, and ZoomText users can locate and recover from error conditions. Recover from an error using Dragon. |
| 3.3.2 Labels or Instructions |
| Labels or instructions are provided when content requires user input. |
| Test Plan |
| For Web forms, show how visible labels are connected in the code to the fields they label, either by showing how they are formed in HTML or by using a tool that shows the accessible name of fields. For software forms, use Inspect or Java Ferret to inspect the accessible name, role, and description of each control (Inspect for Windows Software; Ferret for Java Applets). With JAWS, navigate through each form and show how JAWS announces field labels. Ensure that all form controls, associated labels and instructions are clearly visible with ZoomText running and magnification set to 4x. Check that forms can be completed using Dragon and either direct voice access, flagging controls of the same type, or speaking keyboard commands. |
| 3.3.3 Error Suggestion |
| If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. |
| Test Plan |
| Verify that a list of suggestions for correcting an error condition are presented to the user. Make sure that a list of possible suggestions for correcting an error condition are announced by JAWS. Learn if a list of possible suggestions for correcting an error condition are put in focus by ZoomText. |
| 3.3.4 Error Prevention (Legal, Financial, Data) |
| For content that causes legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, the user can reverse, correct, or confirm the action. |
| Test Plan |
| Verify a user can recover from an error because it is reversible, checked, or confirmed. |
| 4.1.1 Parsing |
| In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. |
| Test Plan |
| Look for markup issues that would prevent pages from being correctly rendered by assistive technologies. |
| 4.1.2 Name, Role, Value |
| For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. |
| Test Plan |
| Use Chromium Edge's Inspect tool to show programmatic focus. Use the Inspect Objects tool to display programmatic focus. Show that each element is announced by JAWS when it gains programmatic focus. Verify focused elements move into the visible magnified area of the screen. Demonstrate that spoken keyboard commands can be used to set focus to elements. |
Verify any changes in state or value are indicated in text or programmatically as revealed by Edge's Inspect, Window's Inspect, or Java Ferret. Make sure changes of state and role are announced so that a user of JAWS is made aware of such changes.
2: Functional Performance Criteria
| 301.1 Scope: Functional Performance Criteria |
| The requirements of Chapter 3 shall apply to ICT where required by 508 Chapter 2 (Scoping Requirements), 255 Chapter 2 (Scoping Requirements), and where otherwise referenced in any other chapter of the Revised 508 Standards or Revised 255 Guidelines. |
| 302.1 Without Vision |
| Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that does not require user vision. |
| Test Plan |
| Using JAWS and keyboard navigation, ensure that all application and administrative functions are available without requiring user vision. Determine if the system can be used without user vision by stepping through use cases with the JAWS screen reader. |
| 302.2 With Limited Vision |
| Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited vision. |
| Test Plan |
| Determine if the system can be used with low vision by stepping through use cases with the ZoomText screen magnifier. Ensure all text, images and multimedia can be magnified. Ensure foreground and background colors can be sufficiently adjusted. Ensure text and images do not pixelate when magnified. Ensure form field labels are visible on-screen when the associated control is magnified. |
| 302.3 Without Perception of Color |
| Where a visual mode of operation is provided, ICT shall provide at least one visual mode of operation that does not require user perception of color. |
| 302.4 Without Hearing |
| Where an audible mode of operation is provided, ICT shall provide at least one mode of operation that does not require user hearing. |
| Test Plan |
| Determine if the system can be used without user hearing by stepping through use cases with sound turned off. Ensure audio is not the sole method for communicating information. Ensure compatibility with the Windows SoundSentry. Ensure synchronized captions are provided for audio portions of multimedia. Ensure all product functionality and content can be accessed when audio output is disabled. |
| 302.5 With Limited Hearing |
| Where an audible mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited hearing. |
| Test Plan |
| Ensure that all application and administrative functions are available through amplified audio output or ensure compatibility with coupled hearing devices. |
| 302.6 Without Speech |
| Where speech is used for input, control, or operation, ICT shall provide at least one mode of operation that does not require user speech. |
| Test Plan |
| Determine if system can be used without user speech by stepping through use cases without speaking. Ensure speech is not the sole method of providing input. Ensure compatibility with assistive technologies that provide alternatives to human speech. |
| 302.7 With Limited Manipulation |
| Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that does not require fine motor control or simultaneous manual operations. |
| Test Plan |
| Use the application with voice command software. Ensure users can access information and functionality using Dragon. |
| 302.8 With Limited Reach and Strength |
| Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that is operable with limited reach and limited strength. |
| Test Plan |
| Use the application with voice command software. Ensure users can access information and functionality using Dragon. |
| 302.9 With Limited Language, Cognitive, and Learning |
| ICT shall provide features making its use by individuals with limited cognitive, language, and learning abilities simpler and easier. |
3: Support Documentation and Services
| 601.1 Scope: Support Documentation and Services |
| The technical requirements in Chapter 6 shall apply to ICT support documentation and services where required by 508 Chapter 2 (Scoping Requirements), 255 Chapter 2 (Scoping Requirements), and where otherwise referenced in any other chapter of the Revised 508 Standards or Revised 255 Guidelines. |
| 602.1 General: Support Documentation |
| Documentation that supports the use of ICT shall conform to 602. |
| 602.2 Accessibility and Compatibility Features |
| Documentation shall list and explain how to use the accessibility and compatibility features required by Chapters 4 and 5. Documentation shall include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology. |
| Test Plan |
| Determine if end-users have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge. Summarize the accessibility and compatibility features of the system. Indicate where these features are described. |
| 602.3 Electronic Support Documentation |
| Documentation in electronic format, including Web-based self-service support, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1). |
| Test Plan |
| Evaluate documents to ensure that they are directly provided in an accessible alternative form or there is a mechanism in place to request and create alternative formats. Ensure documents can be enlarged to various sizes of hardcopy output. Ensure documents are machine-readable by text-to-speech software. Ensure all images, figures and diagrams have informative textual alternatives. Ensure all charts and tables are readable when converted to alternate formats. Ensure alternatives to audio and visual directives, color coding and location and spatial terminology are provided. |
| 602.4 Alternate Formats for Non-Electronic Support Documentation |
| Where support documentation is only provided in non-electronic formats, alternate formats usable by individuals with disabilities shall be provided upon request. |
| 603.1 General: Support Services |
| ICT support services including, but not limited to, help desks, call centers, training services, and automated self-service technical support, shall conform to 603. |
| 603.2 Information on Accessibility and Compatibility Features |
| ICT support services shall include information on the accessibility and compatibility features required by 602.2. |
| 603.3 Accommodation of Communication Needs |
| Support services shall be provided directly to the user or through a referral to a point of contact. Such ICT support services shall accommodate the communication needs of individuals with disabilities. |
| Test Plan |
| Evaluate the application support process to ensure mechanisms are in place for all users with disabilities to receive equivalent access to support material, personnel, and services. Determine if support services for products accommodate the communication needs of end-users with disabilities. Describe the support services for products. Describe the needs of users with disabilities. State how the support services meet the needs of users with disabilities. |
4: Hardware
| 401.1 Scope: Hardware |
| The requirements of Chapter 4 shall apply to ICT that is hardware where required by 508 Chapter 2 (Scoping Requirements), 255 Chapter 2 (Scoping Requirements), and where otherwise referenced in any other chapter of the Revised 508 Standards or Revised 255 Guidelines. EXCEPTION: Hardware that is assistive technology shall not be required to conform to the requirements of this chapter. |
402 Closed Functionality
| 402.1 General: Closed Functionality |
| ICT with closed functionality shall be operable without requiring the user to attach or install assistive technology other than personal headsets or other audio couplers, and shall conform to 402. |
| 402.2 Speech-Output Enabled |
| ICT with a display screen shall be speech-output enabled for full and independent use by individuals with vision impairments. |
EXCEPTIONS:
1. Variable message signs conforming to 402.5 shall not be required to be speech-output enabled.
2. Speech output shall not be required where ICT display screens only provide status indicators and those indicators conform to 409.
3. Where speech output cannot be supported due to constraints in available memory or processor capability, ICT shall be permitted to conform to 409 in lieu of 402.2.
4. Audible tones shall be permitted instead of speech output where the content of user input is not displayed as entered for security purposes, including, but not limited to, asterisks representing personal identification numbers.
5. Speech output shall not be required for: the machine location; date and time of transaction; customer account number; and the machine identifier or label.
6. Speech output shall not be required for advertisements and other similar information unless they convey information that can be used for the transaction being conducted.
| 402.2.1 Information Displayed On-Screen |
| Speech output shall be provided for all information displayed on-screen. |
| 402.2.2 Transactional Outputs |
| Where transactional outputs are provided, the speech output shall audibly provide all information necessary to verify a transaction. |
| 402.2.3 Speech Delivery Type and Coordination |
| Speech output shall be delivered through a mechanism that is readily available to all users, including, but not limited to, an industry standard connector or a telephone handset. Speech shall be recorded or digitized human, or synthesized. Speech output shall be coordinated with information displayed on the screen. |
| 402.2.4 User Control |
| Speech output for any single function shall be automatically interrupted when a transaction is selected. Speech output shall be capable of being repeated and paused. |
402.2.5 Braille Instruction
Where speech output is required by 402.2, braille instructions for initiating the speech mode of operation shall be provided. Braille shall be contracted and shall conform to 36 CFR part 1191, Appendix D, Section 703.3.1. EXCEPTION: Devices for personal use shall not be required to conform to 402.2.5.
| 402.3 Volume |
| ICT that delivers sound, including speech output required by 402.2, shall provide volume control and output amplification conforming to 402.3. EXCEPTION: ICT conforming to 412.2 shall not be required to conform to 402.3. |
| 402.3.1 Private Listening |
| Where ICT provides private listening, it shall provide a mode of operation for controlling the volume. Where ICT delivers output by an audio transducer typically held up to the ear, a means for effective magnetic wireless coupling to hearing technologies shall be provided. |
| 402.3.2 Non-private Listening |
| Where ICT provides non-private listening, incremental volume control shall be provided with output amplification up to a level of at least 65 dB. A function shall be provided to automatically reset the volume to the default level after every use. |
| 402.4 Characters on Display Screens |
| At least one mode of characters displayed on the screen shall be in a sans serif font. Where ICT does not provide a screen enlargement feature, characters shall be 3/16 inch (4.8 mm) high minimum based on the uppercase letter “I”. Characters shall contrast with their background with either light characters on a dark background or dark characters on a light background. |
| 402.5 Characters on Variable Message Signs |
| Characters on variable message signs shall conform to section 703.7 Variable Message Signs of ICC A117.1-2009 (incorporated by reference, see 702.6.1). |
403 Biometrics
403.1 General: Biometrics
Where provided, biometrics shall not be the only means for user identification or control. EXCEPTION: Where at least two biometric options that use different biological characteristics are provided, ICT shall be permitted to use biometrics as the only means for user identification or control.
404 Preservation of Information Provided for Accessibility
| 404.1 General: Preservation of Information Provided for Accessibility |
| ICT that transmits or converts information or communication shall not remove non-proprietary information provided for accessibility or shall restore it upon delivery. |
405 Privacy
| 405.1 General: Privacy |
| The same degree of privacy of input and output shall be provided to all individuals. When speech output required by 402.2 is enabled, the screen shall not blank automatically. |
406 Standard Connections
| 406.1 General: Standard Connections |
| Where data connections used for input and output are provided, at least one of each type of connection shall conform to industry standard non-proprietary formats. |
407 Operable Parts
| 407.1 General: Operable Parts |
| Where provided, operable parts used in the normal operation of ICT shall conform to 407. |
| 407.2 Contrast |
| Where provided, keys and controls shall contrast visually from background surfaces. Characters and symbols shall contrast visually from background surfaces with either light characters or symbols on a dark background or dark characters or symbols on a light background. |
| 407.3 Input Controls |
| At least one input control conforming to 407.3 shall be provided for each function. EXCEPTION: Devices for personal use with input controls that are audibly discernable without activation and operable by touch shall not be required to conform to 407.3. |
| 407.3.1 Tactilely Discernible |
| Input controls shall be operable by touch and tactilely discernible without activation. |
| 407.3.2 Alphabetic Keys |
| Where provided, individual alphabetic keys shall be arranged in a QWERTY-based keyboard layout and the “F” and “J” keys shall be tactilely distinct from the other keys. |
| 407.3.3 Numeric Keys |
| Where provided, numeric keys shall be arranged in a 12-key ascending or descending keypad layout. The number five key shall be tactilely distinct from the other keys. Where the ICT provides an alphabetic overlay on numeric keys, the relationships between letters and digits shall conform to ITU-T Recommendation E.161 (incorporated by reference, see 702.7.1). |
| 407.4 Key Repeat |
| Where a keyboard with key repeat is provided, the delay before the key repeat feature is activated shall be fixed at, or adjustable to, 2 seconds minimum. |
| 407.5 Timed Response |
| Where a timed response is required, the user shall be alerted visually, as well as by touch or sound, and shall be given the opportunity to indicate that more time is needed. |
| 407.6 Operation |
| At least one mode of operation shall be operable with one hand and shall not require tight grasping, pinching, or twisting of the wrist. The force required to activate operable parts shall be 5 pounds (22.2 N) maximum. |
| 407.7 Tickets, Fare Cards, and Keycards |
| Where tickets, fare cards, or keycards are provided, they shall have an orientation that is tactilely discernible if orientation is important to further use of the ticket, fare card, or keycard. |
| 407.8 Reach Height and Depth |
| At least one of each type of operable part of stationary ICT shall be at a height conforming to 407.8.2 or 407.8.3 according to its position established by the vertical reference plane specified in 407.8.1 for a side reach or a forward reach. Operable parts used with speech output required by 402.2 shall not be the only type of operable part complying with 407.8 unless that part is the only operable part of its type. |
| 407.8.1 Vertical Reference Plane |
| Operable parts shall be positioned for a side reach or a forward reach determined with respect to a vertical reference plane. The vertical reference plane shall be located in conformance to 407.8.2 or 407.8.3. |
| 407.8.1.1 Vertical Plane for Side Reach |
| Where a side reach is provided, the vertical reference plane shall be 48 inches (1220 mm) long minimum. |
| 407.8.2.1 Unobstructed Side Reach |
| Where a forward reach is provided, the vertical reference plane shall be 30 inches (760 mm) long minimum. |
| 407.8.2.2 Obstructed Side Reach |
| Where the operable part is located more than 10 inches (255 mm), but not more than 24 inches (610 mm), beyond the vertical reference plane, the height of the operable part shall be 46 inches (1170 mm) high maximum and 15 inches (380 mm) high minimum above the floor. The operable part shall not be located more than 24 inches (610 mm) beyond the vertical reference plane. |
| 407.8.3 Forward Reach |
| Operable parts of ICT providing a forward reach shall conform to 407.8.3.1 or 407.8.3.2. The vertical reference plane shall be centered, and intersect with, the operable part. Where a forward reach allows a reach over a portion of the ICT, the height of that portion of the ICT shall be 34 inches (865 mm) maximum. |
| 407.8.3.1 Unobstructed Forward Reach |
| Where the operable part is located at the leading edge of the maximum protrusion within the length of the vertical reference plane of the ICT, the operable part shall be 48 inches (1220 mm) high maximum and 15 inches (380 mm) high minimum above the floor. |
| 407.8.3.2 Obstructed Forward Reach |
| Where the operable part is located beyond the leading edge of the maximum protrusion within the length of the vertical reference plane, the operable part shall conform to 407.8.3.2. The maximum allowable forward reach to an operable part shall be 25 inches (635 mm). |
| 407.8.3.2.1 Operable Part Height for ICT with Obstructed Forward Reach |
| The height of the operable part shall conform to Table 407.8.3.2.1: |
Reach Depth: Less than 20 inches (510 mm); Operable Part Height: 48 inches (1220 mm) maximum Reach Depth: 20 inches (510 mm) to 25 inches (635 mm); Operable Part Height: 44 inches (1120 mm) maximum
| 407.8.3.2.2 Knee and Toe Space under ICT with Obstructed Forward Reach |
| Knee and toe space under ICT shall be 27 inches (685 mm) high minimum, 25 inches (635 mm) deep maximum, and 30 inches (760 mm) wide minimum and shall be clear of obstructions. |
EXCEPTIONS:
1. Knee and toe space under ICT shall be 27 inches (685 mm) high minimum, 25 inches (635 mm) deep maximum, and 30 inches (760 mm) wide minimum and shall be clear of obstructions.
2. At a depth of 6 inches (150 mm) maximum from the vertical reference plane toward the leading edge of the ICT, space between 9 inches (230 mm) and 27 inches (685 mm) minimum above the floor shall be permitted to reduce at a rate of 1 inch (25 mm) in depth for every 6 inches (150 mm) in height.
408 Display Screens
| 408.1 General: Display Screens |
| Where provided, display screens shall conform to 408. |
| 408.2 Visibility |
| Where stationary ICT provides one or more display screens, at least one of each type of display screen shall be visible from a point located 40 inches (1015 mm) above the floor space where the display screen is viewed. |
| 408.3 Flashing |
| Where ICT emits lights in flashes, there shall be no more than three flashes in any one-second period. EXCEPTION: Flashes that do not exceed the general flash and red flash thresholds defined in WCAG 2.0 (incorporated by reference, see 702.10.1) are not required to conform to 408.3. |
409 Status Indicators
| 409.1 General: Status Indicators |
| Where provided, status indicators shall be discernible visually and by touch or sound. |
410 Color Coding
| 410.1 General: Color Coding |
| Where provided, color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. |
411 Audible Signals
| 411.1 General: Audible Signals |
| Where provided, audible signals or cues shall not be used as the only means of conveying information, indicating an action, or prompting a response |
412 ICT with Two-Way Voice Communication
| 412.1 General: ICT with Two-Way Voice Communication |
| ICT that provides two-way voice communication shall conform to 412. |
| 412.2 Volume Gain |
| ICT that provides two-way voice communication shall conform to 412.2.1 or 412.2.2. |
| 412.2.1 Volume Gain for Wireline Telephones |
| Volume gain conforming to 47 CFR 68.317 shall be provided on analog and digital wireline telephones. |
| 412.2.2 Volume Gain for Non-Wireline ICT |
| A method for increasing volume shall be provided for non-wireline ICT. |
| 412.3 Interference Reduction and Magnetic Coupling |
| Where ICT delivers output by a handset or other type of audio transducer that is typically held up to the ear, ICT shall reduce interference with hearing technologies and provide a means for effective magnetic wireless coupling in conformance with 412.3.1 or 412.3.2. |
| 412.3.1 Wireless Handsets |
| ICT in the form of wireless handsets shall conform to ANSI/IEEE C63.19-2011 (incorporated by reference, see 702.5.1). |
This is the start of the file's text. The full file is on GovTribe.