In the context of Web or Software, an ADA or Accessibility Audit is a detailed report of a software application or a website implementation ability to meet compliance with guidelines or standards. When referring to Accessibility Audit the assessment is based on ADA Compliance, Section 508 standards, and/or WCAG 2.0/2.1 guidelines. With ADA Compliance Audit – the assessment is specific to ADA and identifies improvements essential to ADA Compliance. An Accessibility Audit could include Level A thru Level AAA WCAG guidelines which are much stricter but aren’t required by an ADA Audit which only requires Level AA compliance.
Why is it Important?
This is important as an ADA Audit is a pass or fail testing process which pertains to the civil laws associated with ADA. We test for Level AAA and stricter guidelines in an Accessibility Audit as it offers essential improvements in the design and implementation of the product – this gives us the best chance of meeting any potential audience using it and by being this strict we cover any potential issues with the pass or fail audit that could lead to a lawsuit against our product. An additional note of clarification – ADA Compliance is actually made up of guidelines from both the latest Section 508 Refresh Standards (ICT Refresh) and WCAG 2.0/2.1 Guidelines, they are not inclusive in “all” of each but instead overlap both.
What does an ADA Audit cover?
Let’s take a look at what’s being tested. Below we will list a summary of WCAG 2.1 guidelines for ADA Compliance. This covers specific categories within WCAG. Please note Levels A & AA required for ADA Compliance. Level AAA is stricter compliance but not required by law. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0.
Table 1 – Summary of WCAG 2.1 Criteria opens a new window
Section |
Overview |
|---|---|
| All “User Interface (UI)” components and information has to be presented in a way users can perceive it. | |
| Any non-text content should be provided alternatives so that it can be modified into other forms needed by users. Examples: larger print, braille, symbols, or simpler language. | |
| Provide alternatives to time-based media. | |
| Content should be designed in such a way as to allow presentation in different ways without losing information or structure. | |
| Content including foreground and background should be made easy for users to see and hear. | |
| All UI components and navigation must be presented in a way users may operate it. | |
| Make all functionality available from a keyboard. | |
| Provide users enough time to read and use content. | |
| Do not design content in a way that is known to cause seizures or physical reactions. | |
| Provide ways to help users navigate, find content, and determine where they are. | |
| Make it easier for users to operate functionality through various inputs beyond the keyboard. | |
| All UI, navigation, and information has to be understandable to the user. | |
| Make text content readable and understandable. | |
| Make Web pages appear and operate in predictable ways. | |
| Help users avoid and correct mistakes. | |
| All content has to be robust enough to be interpreted by a wide variety of user agents including assistive technologies. | |
| Maximize compatibility with current and future user agents, including assistive technologies. | |
| In this section requirements are listed for WCAG 2.1 conformance. It describes what it means to be accessibility supported as only accessibility-supported ways of using technology can be relied upon for conformance. Further explanation of the accessibility-supported concept presented to allow better understanding of conformance. Finally, it also gives information about how to make conformance claims, which is currently optional. | |
| In order for a Web page to conform to WCAG 2.1, all of the listed conformance requirements must be satisfied – see items 5.2.1 – 5.2.5 of the WCAG 2.1 Criteria opens a new window. |
Along with WCAG Criteria, an Accessibility Audit also includes Section 508 Standards as they apply to software, web, web related content, and other forms electronic communication. See the synopsis of standards and guidelines below and where they impact an Audit.
These standards address access to information and communication technology (ICT) under Section 508 of the Rehabilitation Act and Section 255 of the Communications Act.
Section 508 requires access to ICT developed, procured, maintained, or used by federal agencies. Examples include computers, telecommunications equipment, multifunction office machines such as copiers that also operate as printers, software, websites, information kiosks and transaction machines, and electronic documents. The Section 508 Standards, which are part of the Federal Acquisition Regulation, ensure access for people with physical, sensory, or cognitive disabilities.
The Section 255 Guidelines cover telecommunications equipment and customer-premises equipment — such as telephones, cell phones, routers, set-top boxes, and computers with modems, interconnected Voice over Internet Protocol products, and software integral to the operation of telecommunications function of such equipment.
ICT Accessibility 508 Standards and 255 Guidelines opens a new window
Table 2 – Summary of *ICT Refresh (Section 508) opens a new window
* Note: We will look at those criteria that pertain to the web and web related content.
Section/Chapter |
Overview |
|---|---|
| Corresponding WCAG 2.0/2.1 Guidelines | |
| Revised Section 508 | |
|
|
|
|
|
|
|
|
| Revised Section 508 | |
|
|
|
|
|
|
|
|
|
|
| Revised Section 508 | |
|
|
|
|
|
|
| Revised Section 508 | |
|
|
| Revised Section 508 (Applicable Chapters) | |
| Chapter 3 | Functional Performance Criteria opens a new window (FPC) |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | ICT shall provide features making its use by individuals with limited cognitive, language, and learning abilities simpler and easier. |
| Chapter 5 | Software opens a new window |
| 501.1 Scope – Incorporation of WCAG 2.0 AA | |
| 502 Interoperability with Assistive Technology opens a new window | |
| 502.2.1 User Control of Accessibility Features | Platform software shall provide user control over platform features that are defined in the platform documentation as accessibility features. |
| 502.2.2 No Disruption of Accessibility Features | Software shall not disrupt platform features that are defined in the platform documentation as accessibility features. |
| 502.3 Accessibility Services | Platform software and software tools that are provided by the platform developer shall provide a documented set of accessibility services that support applications running on the platform to interoperate with assistive technology and shall conform to 502.3. Applications that are also platforms shall expose the underlying platform accessibility services or implement other documented accessibility services. |
| 502.3.1 Object Information | The object role, state(s), properties, boundary, name, and description shall be programmatically determinable. |
| 502.3.2 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. |
| 502.3.3 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. |
| 502.3.4 Values | Any current value(s), and any set or range of allowable values associated with an object, shall be programmatically determinable. |
| 502.3.5 Modification of Values | Values that can be set by the user shall be capable of being set programmatically, including through assistive technology. |
| 502.3.6 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. |
| 502.3.7 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. |
| 502.3.8 Text | The content of text objects, text attributes, and the boundary of text rendered to the screen, shall be programmatically determinable. |
| 502.3.9 Modification of Text | Text that can be set by the user shall be capable of being set programmatically, including through assistive technology. |
| 502.3.10 List of Actions | A list of all actions that can be executed on an object shall be programmatically determinable. |
| 502.3.11 Actions on Objects | Applications shall allow assistive technology to programmatically execute available actions on objects. |
| 502.3.12 Focus Cursor | Applications shall expose information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface components. |
| 502.3.13 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. |
| 502.3.14 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. |
| 502.4 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:
|
| 503 Applications opens a new window | |
| 503.2 User Preferences | Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor. EXCEPTION: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to 503.2. |
| 503.3 Alternative User Interfaces | Where an application provides an alternative user interface that functions as assistive technology, the application shall use platform and other industry standard accessibility services. |
| 503.4 User Controls for Captions and Audio Description | Where ICT displays video with synchronized audio, ICT shall provide user controls for closed captions and audio descriptions conforming to 503.4. |
| 503.4.1 Caption Controls | Where user controls are provided for volume adjustment, ICT shall provide user controls for the selection of captions at the same menu level as the user controls for volume or program selection. |
| 503.4.2 Audio Description Controls | Where user controls are provided for program selection, ICT shall provide user controls for the selection of audio descriptions at the same menu level as the user controls for volume or program selection. |
| 504 Authoring Tools opens a new window | |
| 504.2 Content Creation or Editing (if not authoring tool, enter “not applicable”) | Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for all supported features and, as applicable, to file formats supported by the authoring tool. Authoring tools shall permit authors the option of overriding information required for accessibility. EXCEPTION: Authoring tools shall not be required to conform to 504.2 when used to directly edit plain text source code. |
| 504.2.1 Preservation of Information Provided for Accessibility in Format Conversion | Authoring tools shall, when converting content from one format to another or saving content in multiple formats, preserve the information required for accessibility to the extent that the information is supported by the destination format. |
| 504.2.2 PDF Export | Authoring tools capable of exporting PDF files that conform to ISO 32000-1:2008 (PDF 1.7) shall also be capable of exporting PDF files that conform to ANSI/AIIM/ISO 14289-1:2016 (PDF/UA-1) (incorporated by reference, see 702.3.1). |
| 504.3 Prompts | Authoring tools shall provide a mode of operation that prompts authors to create content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for supported features and, as applicable, to file formats supported by the authoring tool. |
| 504.4 Templates | Where templates are provided, templates allowing content creation that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) shall be provided for a range of template uses for supported features and, as applicable, to file formats supported by the authoring tool. |
| Chapter 6 | Support Documentation and Services opens a new window |
| 601.1 Scope | 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 Support Documentation opens a new window | |
| 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. |
| 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). |
| 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 Support Services opens a new window | |
| 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. |
How are these Audits Accomplished?
An Audit, whether Accessibility in general or focused on ADA specifically, uses a combination of automated tools and manual testing to verify content and access. I will be adding an article soon regarding the type of tools available for different types of testing and evaluation as well as a pro and con list for each. In the meantime be sure to check out my “Easy Guide to Website Accessibility and ADA Compliance.”
