AT-Free Testing Scripts?
In the accessibility world, our focus is on making sure that users with disabilities-- including those who use assistive technologies (AT)-- are able to access and interact with digital media as easily and robustly as users without disabilities. So why in the world did we add testing scripts in WebAlign that completely avoided using AT? Simple. It's because the vast majority of developers and testers will be unable to use AT effectively in their testing.
I can fully relate to the plight of the average developer or tester. I would be completely lost if I had to rely on a screen reader to access my computer. Just tabbing between controls is easy enough, but then once you add in skipping between links and landmarks or headings and graphics-- and being forced to memorize each of the different commands to do each task-- and I would just be lost. Of course, I know that I would get proficient at it with weeks and weeks of practice-- and relying on a screen reader for all of my work. But, because I don't spend those weeks and weeks now, I will never get proficient at it. And neither will 99% of developers and testers out there.
Are You Saying AT Testing Has No Place?
Absolutely not! In fact, I think that getting developers and testers to do WCAG testing without assistive technology just reinforces the need for AT testing-- it's just that that AT testing needs to be done by someone who really knows what they are doing and can give developers and testers more insight into practical design and development strategies. One thing that shouldn't be done is to expect the average developer or tester to understand the experience of users with disabilities just by fumbling around with a screen reader that they never use.
And just to bring this point home even more clearly, we are also working with our colleagues at Outlook Business Solutions to develop testing steps that require the use of assistive technology. Jeff is infinitely better at using a screen reader than I am-- and he's way better at it than the average accessibility tester. But he still doesn't use a screen reader 24x7.
What Do These Testing Scripts Look Like?
In WebAlign, we have 13 easy test scripts that cover all of WCAG 2.1 A/AA. A lot of these scripts will only be used occasionally by some testers (e.g. Testing Dynamic and Time-Based Media Content only comes up if the page includes videos) so a typical test pass can be done really quickly!
Within each test script, we describe free tools (e.g. accessibility bookmarklets) that your developers and testers can use to check that the markup that they create meets specific WCAG requirements. For instance, in the screenshot below, we describe how to install and use both (1) the Headings Accessibilty Bookmarklet and (2) the headingsMap extension for Chrome-- and then we give specific pass/fail test criteria that developers and testers can use to assess whether they have met specific WCAG Success Criteria.
What About Testing Specifc WCAG Success Criteria?
One of the neat features about WebAlign is its granularity. For instance, one of WCAG 1.3.1's many requirements is that header structure has to follow a logical, outline-like structure. We capture that in "Core Concept" 1.3.1.1 (notice the extra digit placed at the end). This extra granularity means that WebAlign can specify strategies for meeting JUST header structure. And, when you include the other six Core Concepts under Success Criteria 1.3.1, you pretty much have WCAG Success Criteria 1.3.1 completely covered.
We can also divvy up the test scripts to be specific to success criteria. So, for instance, we can take this same example and give a clear test process (with and without using assistive technology) for meeting a portion of Success Criteria 1.3.1. This is show in the following screenshot from WebAlign. In this example, the non-AT test script comes out of our 13 test scripts and the AT test scripts was developed along with feedback from Outlook Business Solutions.
VPAT Anyone?
You can kind of see where this is all going. If developers can easily verify that they are meeting every WCAG Success Criteria before testers verify they've met WCAG, it means that organizations can see how their products comply with WCAG during the development process. But, WebAlign even does that for pre-production teams.
A Voluntary Product Accessibility Template (VPAT) is an industry-standard method that governments, educational institutions, and other large organizations use to verify the accessibility of products that they are buying. The VPAT is structured around the Section 508 Standards, which are developed by the U.S. Access Board. The latest iteration of the Section 508 standards, of course, uses the WCAG A/AA Success Criteria. And because our checklists track to WCAG, this means that our customers can track their VPAT development at each stage of the process. This means winning more contracts because Section 508 requires the Federal government to buy the most accessible product. It also means less last-minute redesigns and retrofits to create an acceptable VPAT.
Getting to Real Accessibility
Creating a simple set of accessibility testing scripts that syncs up well with WCAG fills our vision of promoting a seamless accessibility model with our customers. We believe that accessibility should be deeply "baked in" for our customers-- it shouldn't be a costly add-on. The first step to meeting this model is to create a robust compliance model that isn't hard to use. WebAlign's logical set of Core Concepts, actionable checklists, and AT-free testing scripts meet this goal.
People tend to like to do what they already do well. Give them easy tools to accomplish basic things and they can get really good at them. At that point, it's much easier to introduce more difficult ideas-- for instance, real screen reader testing. Almost every successful accessibility program we've worked with started with the basics and used that as a platform for moving forward. Don't think of our AT-free testing scripts as the best way to do accessibility testing; instead, think of them as a WCAG compliance tool that you can use as a stepping stone to a world-class accessibility program.
The Bigger Picture
If you've been watching WebAlign develop over the last six months, you may be able to sense our vision.
- First, we started with breaking down WCAG into a set of actionable and logical Core Concepts.
- Next, we took those Core Concepts and identified compliance steps at the design, development, and testing stages. We then used those steps to create role-specific checklists for designers, developers, and testers.
- Next, we refined the testing process so that developers and testers can easily verify that their code met the standards.
This leaves design and development for further refinement. We know exactly what needs to be done here and we can't wait to start folding these elements into WebAlign as well.
Our vision for WebAlign is a fully integrated design-development-QA model for accessibility. We can't wait to show you what comes next!
Why wait? Schedule a demo of WebAlign for your organization today!
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “Why We Created WCAG Testing Scripts That Don’t Use Assistive Technology”