This checklist is for Chapter 5 of the final rule. When internal reference numbers are used (i.e. 501.1) they refer to the specific paragraph in the final rule 501.1 (Chapter 5 Section 501 subsection 1). External reference numbers are contained in Chapter 7: Reference Standards of the final rule.
Scope. The requirements of Section 508, Chapter 5 shall apply to software where required by Section 508, Chapter 2 (Scoping Requirements), Section 255 of the Communications Act, Chapter 2 (Scoping Requirements), and where otherwise referenced in any other chapter of the Revised 508 Standards or Revised 255 Guidelines.
Exception: Where Web applications do not have access to platform accessibility services and do not include components that have access to platform accessibility services, they shall not be required to conform to Section 508, Chapter 5, 502 or 503 provided that they conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).
E201.1 Scope. Information and Communication Technology (ICT) that is procured, developed, maintained, or used by agencies shall conform to the Revised 508 Standards.
E205.4 Accessibility Standard. Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference). For referenced standards, including the Web Content Accessibility Guidelines and Section 255 of the Communications Act, See Chapter 7.
You may access a customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2 requirements (success criteria) and techniques.
Severity Level Grading Criteria
Critical: This issue results in severe barriers for users with disabilities, either because content is blocked or functionality is inoperable. It causes global issues across the project because people with disabilities are unable to use it. This violation must be resolved before content/functionality can be considered fully compliant. Remediation should be a top priority.
High: This issue results in significant barriers for individuals with disabilities. Some important content/functionality is not accessible. Users of Assistive Technology may not be able to access all content and/or functionality. Remediation should be a priority.
Medium: This issue results in some barriers for individuals with disabilities but will not prevent them from accessing fundamental elements or content. This violation must be resolved before content/functionality can be considered fully compliant.
Low: This issue causes minimal impact for users with disabilities. This may be a technical violation of the law but doesn’t make the content inaccessible. This content/functionality should be remediated in order to be considered fully compliant, but remediation can be given a low priority.
Platform Software Success Criteria Checklist
Download the Platform Software Success Criteria Checklist (PDF, 6 pages, 107 KB)
| Reference Number | Severity Level | Platform Software Success Criteria | Yes, No, or Not Present |
|---|---|---|---|
| 502.2.1 | Critical | User Control of Accessibility Features. Platform software shall provide user control over platform features that are defined in the platform documentation as accessibility features.Is there at least one mode of input/output operation accessible to a blind person for each feature in the program? Are the accessibility features of the platform software available to the user to control? | |
| 502.2.2 | High | No Disruption of Accessibility Features. Software shall not disrupt platform features that are defined in the platform documentation as accessibility features. Is there at least one mode of input/output operation accessible to a user with limited vision for each feature in the program? Does the software platform avoid disrupting the underlying platforms accessibility features? | |
| 502.3.1 | Critical | Object Information. The object role, state(s), properties, boundary, name, and description shall be programmatically determinable. Can the assistive technology software discern the object information exposed by the software running on the platform? | |
| 502.3.2 | Low | Modification of Object Information. States and properties that can be set by the user shall be capable of being set programmatically, including through assistive technology.. Can the assistive technology user set the object value correctly? | |
| 502.3.3 | High | Row, Column, and Headers. If an object is in a data table, the occupied rows and columns, and any headers associated with those rows or columns, shall be programmatically determinable. Can the assistive technology software discern the row and column header information exposed by the software running on the platform? | |
| 502.3.4 | Critical | Values. Any current value(s), and any set or range of allowable values associated with an object, shall be programmatically determinable. Can the assistive technology software discern the value and range of value information exposed by the software running on the platform? | |
| 502.3.5 | Low | Modification of Values. Values that can be set by the user shall be capable of being set programmatically, including through assistive technology. Are all features of the application keyboard accessible? Can the assistive technology user set the value correctly? | |
| 502.3.6 | Critical | Label Relationships. Any relationship that a component has as a label for another component, or of being labeled by another component, shall be programmatically determinable. Can the assistive technology software discern the label of the component when the focus in on the component? | |
| 502.3.7 | Medium | Hierarchical Relationships. Any hierarchical (parent-child) relationship that a component has as a container for, or being contained by, another component shall be programmatically determinable. Are all features of the application accessible to a user with limited learning abilities? Can the assistive technology software discern the hierarchical relationship of the components when the focus is on the component? | |
| 502.3.9 | Low | Modification of Text. Text that can be set by the user shall be capable of being set programmatically, including through assistive technology. Can the assistive technology user set the text correctly for an object that allows non-AT user to set the text value without using a mouse? | |
| 502.3.10 | Critical | List of Actions. A list of all actions that can be executed on an object shall be programmatically determinable. Can the assistive technology software discern the actions available on the component when the focus is on the component? | |
| 502.3.11 | Critical | Actions on Objects. Applications shall allow assistive technology to programmatically execute available actions on objects. Can the assistive technology user execute the actions on the drop down box correctly? | |
| 502.3.12 | Critical | Focus Cursor. Applications shall expose information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface components. Can the assistive technology see the visible focus as the user uses the keyboard only and TABS through the application? Can the assistive technology user see a visible indicator when focus is on a field that accepts text input? Are there no hidden areas that gain focus? | |
| 502.3.13 | Low | Modification of Focus Cursor. Focus, text insertion point, and selection attributes that can be set by the user shall be capable of being set programmatically, including through the use of assistive technology. Can the assistive technology user see the focus and text insertion points? | |
| 502.3.14 | Critical | Event Notification. Notification of events relevant to user interactions, including but not limited to, changes in the component’s state(s), value, name, description, or boundary, shall be available to assistive technology. Are the accessibility fields of the software components running on the platform correctly captured after the notification events are sent? | |
| 502.4 | Low | Platform Accessibility Features. Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (2008) (incorporated by reference, see 702.4.1) listed below: -Section 9.3.3 Enable sequential entry of multiple (chorded) keystrokes; -Section 9.3.4 Provide adjustment of delay before key acceptance; -Section 9.3.5 Provide adjustment of same-key double-strike acceptance; -Section 10.6.7 Allow users to choose visual alternative for audio output; -Section 10.6.8 Synchronize audio equivalents for visual events; -Section 10.6.9 Provide speech output services; and -Section 10.7.1 Display any captions provided. |
