In the last few blog posts from this column, we’ve discussed the importance of focusing on core accessibility rules when it comes to tackling web accessibility requirements so designers and developers really understand what the different WCAG 2.0 guidelines and Success Criteria mean. Prior to that, we had also discussed the importance of leaving designers and developers some breathing room so they could come up with their own innovative solutions based on their understanding of those core rules.
Now that we’ve established these parameters, it’s time to get to the meat and potatoes of what this column is meant to be, and that is discussing the different aspects of web accessibility testing. Web accessibility testing is an important part of most web accessibility subject matter experts. My experience suggests that most people have their own way of doing things, and while there are usually similar patterns, no two evaluators share identical methodologies.
At Deque, we’ve worked hard this past year on improving our internal processes so we can guarantee as much consistency as possible between the findings of different resources when more than one expert is assigned to a project (which happens quite frequently). This means:
- Testing for similar things (assumes a common understanding of core rules),
- Following a specific testing process (assumes an official testing methodology),
- Relying on the same tools (assumes an agreement on which tools are best),
- Reporting issues (assumes a common interpretation of accessibility barriers),
- Proposing recommendations (assumes a common remediation library).
While it obviously helps to be an “accessibility expert” when it comes to testing web pages for accessibility, this is not always mandatory. Which is a good thing because most people I meet who are tasked with the responsibility of doing web accessibility testing are not accessibility experts.
What I’ve found out over the years is that most people that get assigned to this task often come from non-technical backgrounds. So while having ownership of this expertise is valuable, I believe most people can still do web accessibility testing efficiently if they follow a certain recipe.
Providing you with such a recipe now becomes the main objective of this monthly column so we can hone our skills together, validate approaches, and be up and running in no time. While this is going to be targeted at people who would be new to web accessibility testing, I’m hoping these posts can spark some interesting conversations in the months to come with actual experts who would happen to drop by as well.
What evaluators truly need is not extensive expertise but rather a fundamental understanding of the goals pursued when creating accessible content. Coupled with a reliable method to run testing, most stakeholders and QA specialists can pick up on the skill rather quickly so Web accessibility barriers can be identified, analyzed, and a recommendation for remediation can be provided.
Doing web accessibility testing requires a certain mindset. By following the twelve core rules presented earlier and keeping them in mind at all times, it should be possible for anyone using a reliable checklist to get started doing Web accessibility testing.
Getting the Broader Picture
The whole point of web accessibility testing is to find issues or barriers that users with disabilities might run into while they surf the Web using various assistive technologies. Hopefully, the discoveries we make as evaluators can provide developers and designers with recommendations so improvements can be made to the overall user experience of the product, application, or web site.
To be able to do this, the evaluator needs to be able to somewhat replicate the context through which some of these users are experiencing the web. This is where assistive technologies and tools come into play. You will very quickly discover problems, if any, by navigating through the page using a screen reader. One of the very first things you will realize is that it’s not because the page looks good visually that it has been structured properly in the underlying code. Often times, a page that actually looks really good from an usability or even accessibility standpoint might prove to be a total disaster once we start navigating through it with a screen reader.
The Web Accessibility Evaluation Process usually boils down to five (5) key points:
1. Defining the Scope of the Evaluation
Determine how many pages will be evaluated, selecting representative pages, choosing which conformance level to evaluate against, etc.
2. Running an automated scan of the page
Use a specific tool to find issues that can be found automatically and report those as a foundation for the work to come in the manual testing phase.
3. Conducting a manual testing audit
Go through a series of test using different tools to find all the issues that are present in the page or application that is being tested.
4. Using a screen reader to test for accessibility
Listen to the web site or application using a specific screen reader/browser combination, discover otherwise invisible user issues, etc.
5. Documenting all findings in an accessibility report format
Bring all the findings together into a comprehensive and usable format that allows stakeholders to remediate the issues found based on recommendations.
Stay tuned, as we’ll jump in the details of each of these phases imply in the upcoming posts!
Denis is a Web accessibility consultant working for Deque Systems from Montreal, Canada. He has been helping organizations of all sizes build a better, more accessible Web for everyone since 2000.