How do I determine if my web site or application is Section 508 compliant?
By far the most common question we receive here at SSB BART Group is how do I determine if this thing is 508 compliant? To answer that question we have to at three key questions. To be 508 compliant you have to be able to answer each question in the affirmative. The questions are:
- Did we write the application in a fashion that conforms to the coding requirements in the relevant standards? Did we code it right? (Technical Requirements)
- Can people with disabilities using the application complete the core tasks of the application? Does the application as a whole produce an accessible experience? Can people with disabilities use it? (Functional Requirements)
- Is the deployment context of the application accessible? Does the information, documentation, support and training produce an accessible experience? (Support Requirements)
The technical requirements – in the reference language of Section 508 for web based systems these are commonly §1194.21 and §1194.22 – require a system to have a conformant technical implementation. Basically this means the code of the application has to conform to some specific requirements.
The technical requirements are, by far, the requirements people are most familiar with. In the case of §1194.21 this is a series of twelve paragraphs – in the case of §1194.22 it’s a set of sixteen paragraphs. Most of the time when we talk to people about 508 compliance – and they know anything – they know about these paragraphs.
At SSB we take each of those paragraphs and break them down into best practices we test for compliance. So, as an example, if we consider §1194.21 – Software Applications and Operating Systems paragraph (a) the standard language is When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. That paragraph – §1194.21 (a) – then maps into a variety of best practices which need to be validated:
- Avoid the sole use of device dependent event handlers
- Ensure embedded objects are device-independent
- Ensure all active elements can receive keyboard focus
- Ensure keyboard focus is not provided to inactive elements
- Ensure menus can be opened from the keyboard
- Ensure sub-menu items are keyboard accessible and contain text equivalents
- Ensure selectable rows are keyboard accessible
- Ensure content updates define focus updates appropriately
- Ensure calendar components are keyboard accessible
- Ensure event handlers that trigger focus changes are avoided
- Ensure the tab order of interactive elements on the page is logical
- Avoid forced focus changes that the user is not aware of
- Ensure that simulated dialogs can be closed via the keyboard
- Ensure that simulated dialogs are rendered inline with the controls that activate them
- Ensure all read-only edit elements can receive keyboard focus
- Ensure tree and outline node components are accessible from the keyboard
- Ensure simulated controls are keyboard accessible
- Ensure sortable headers can be triggered from the keyboard
- Ensure that simulated calendars are rendered inline with the controls that activate them
- Ensure the keyboard can be used to navigate through or past the embedded content
- Ensure keyboard focus can be moved away from keyboard accessible components
- Ensure server-side image maps are avoided
- Ensure event handlers that trigger navigation or form submission are avoided
- Provide a mechanism for skipping past repetitive navigation links
- Ensure a valid skip link target is present and is located appropriately
Each of those best practices, in turn, are classified based on how they are tested. Broadly speaking they can be tested either Automatically (24.8%), Manually (48.3%) and Globally (26.9%)
Automatic testing is the cheapest and most common testing but covers only a small fraction of legal requirements. Automatic tests are requirements that can be tested for automatically with a high degree of certainty. Automatic testing covers around 25% of applicable accessibility requirements the rest of which need to be tested manually or globally. In almost all cases automatic tests generally don’t allow you to determine full compliance with the laws, for example:
- Tools can test for the presence of alternative text but not if the text is a meaningful replacement. The latter is the legal requirement.
- Tools can test for the presence of form field labels but not if assistive technology users can fill out a form. That latter is the legal requirement.
Bottom line – if someone tells you that you can buy a tool to test for Section 508 compliance automatically they are selling you a bill of goods. Run.
Global testing relates to the issues that can be tested once or a small number of times and extrapolated across the entire application. This is stuff like color palette selections, CSS usage, error handling and indication, system timeouts and other, systemically handled issues.
Manual testing relates to the issues that can be validated on a page-by-page, in SSB terms a module-by-module, basis but can’t be validated across the entire application. All requirements that don’t fit the automatic or global profile are by nature manual requirements.
In terms of testing the Technical Requirements we basically build a big test matrix and fill in results. On one axis of the matrix we have the set of best practices that are relevant. For the standard audit we do – against Section 508 and WCAG 2.0 A and AA in the context of browser native technology – we get a set of about 180 best practices we are validating conformance to. On the other axis of the matrix we have the individual pieces of the application we are testing. Generally in the context of a web based system these are either web pages or portions – commonly UI widgets – in the overall page. We then essentially go through and validate for each component we are testing that it conforms to all the required best practices. This results in several thousand unit tests in each application so we have a lot of techniques we use to execute the tests more rapidly as well as quickly grouping the reporting of similar issues.
The functional requirements – in the context of Section 508 §1194.31 – require a system to be usable to people with disabilities using current assistive technologies. If you think of the technical requirements as the trees you can think of the functional requirements as the forest. The functional requirements are basically saying, as a whole, can this system be used by individuals with disabilities. Section 508 actually calls out six different specific disabilities types that require functional conformance under the law:
- People that are blind or visually impaired;
- People with visual acuity less than 20/70 ;
- People that are deaf or hard of hearing;
- People that use assistive hearing devices;
- People that cannot or have a difficulty producing speech;
- People that lack fine motor control, have limited reach or strength and generally have an impairment of an axis of motion.
To test functional conformance we define a set of use cases for the application – basically core tasks – and then execute those core tasks across a set of assistive technologies. The assistive technologies are used and operated by individuals with disabilities. The users report back on both the ability to execute individual use cases in the application as well as the overall usability of the application as a whole. The results are rated on a one to five Likert scale with certain ratings (1 and 2) representing a fail and the rest representing degrees of ease for the pass. The data is then crunched across all use cases and relevant user requirements to determine the overall compliance level of the application.
The final requirement is to determine if the overall deployment context of the system is accessible. Generally this means ensuring that the product documentation, training and support systems are accessible to individuals with disabilities. During this phase we analyze the following general areas:
- If the application’s electronic documents are provided in an accessible format;
- If there is a means of providing real time, accessible communications . This can be via TTY / TDD in the old school implementation or via accessible online chat in the modern form.
- If the training that supports and is provided with the application is accessible?
Yes, you must conform to every part
The key thing to remember is that an application must conform to the technical, functional and support requirements to be considered compliant. If you conform to the technical standards but don’t support real world operation by someone with disabilities, functional conformance, you do not conform. In the same vein if the application can be used by someone with JAWS but the code doesn’t conform to the standards you are not compliant. You have to conform to all the requirements to conform to the standards.