The Conversion Process

Basically, for any accessibility standard you have two broad sets of requirements you need to satisfy to be considered compliant:

* Technical Requirements – (§1194.21 & §1194.22) – Is the site formatted in a fashion that conforms to the coding requirements in the relevant standards? Basically, is the code to spec?
* Functional Requirements – (§1194.31) – Can people with disabilities complete the core tasks of the site? Does the site as a whole produce an accessible experience for users with disabilities?

To audit the technical requirements most organizations take a representative  set of pages in the application  and validate them against a set of best practices. This is the auditing process most people are familiar with and the starting point for most organizations. That validation breaks down into three testing requirement buckets based on how a best practice can be tested – automatically (24.8%), manually (48.3%) or globally (26.9%):

Many services only provides coverage for the automatic tests. While automatic testing is the cheapest and most common testing it covers only about one quarter of your legal requirements. The rest of the applicable technical requirements need to be tested manually or globally. In practice that means if you do not complete manual or global testing it is highly likely you will NOT BE COMPLIANT WITH THE LAW.

Testing support for global and manual items is provided via a set of best practices. These best practices define unit tests that must be executed to validate compliance. For the average site testing the twelve paragraphs of §1194.21 and the sixteen paragraphs of §1194.22 requires validating against one hundred and twenty best practices. So you be aware that while you have a small number of paragraphs your actual validation requirements are going to be far more extensive.

The second area that must be validated is functional conformance which has to do with the usability of the system by individuals with disabilities. If you think of the technical requirements as the trees the functional requirements are the forest. The standard for functional testing is validation across all the core use cases of your application with three key assistive technologies – JAWS, ZoomText and Dragon. The goal is validating that a user with a disability using those assistive technologies can execute a task in the application – basically they can use the application.

The key challenge in terms of functional compliance is ensuring you have access to users with disabilities who can test your application. While testing internally with assistive technologies is laudable it will not simulate the user experience of an individual with disabilities an general results in more false positives and omitted negatives than valid test results.