Every week, the Converge Accessibility team meets for two hours with Greg Rogers from Outlook Business Solutions to develop test scripts that users with disabilities can leverage in testing websites for compliance with the W3C’s Web Content Accessibility Guidelines (WCAG) 2.1 A/AA. The results of this work feeds into WebAlign, a tool organizations use to manage and track WCAG compliance from the design phase, through development, and into testing. Previously, Converge Accessibility developed a set of test scripts that enabled developers and testers to test without resorting to assistive technology. This makes sense because everyday testers can’t be expected to become proficient screen reader users when their jobs require them to test far more than just accessibility. But testing without assistive technology doesn’t give any sense to the real-world impact of websites on users with disabilities—and this is why Converge Accessibility and others have turned to Outlook Business Solutions.
But, as this week’s post explains, organizations can’t simply let just any users with disabilities perform accessibility testing! Unless you choose the right users with disabilities to perform accessibility testing, you could open yourself up to potential litigation and make life harder for many of your customers with disabilities!
“Limitations” of some assistive technologies
The first problem comes up with screen readers (*cough* JAWS® *cough*) that overcompensate for bad web designs. Many of these “optional” features are hard to find in the screen readers, so it is hard to tell whether the page is designed correctly—or whether the screen reader is compensating for bad design.
Tables are a great example. Shown below is a screenshot of the general salary table for civilian federal employees by the Office of Personnel Management. Anyone who has worked in the federal government knows this table very well.
Down the left side of the table are the “grades,” and along the top row are the “steps.” All federal salaries are a combination of grade and step. For instance, to know the salary for grade 11 step 6 requires going to the 11th row and sixth column and finding the value 65,051. If you’re using a screen reader to navigate this table, it can quickly become a sea of numbers unless the row and column are read out to you. For instance, hearing just “61,133; 63,192; 65,051…” tells the user nothing unless they have a phenomenal memory. Instead, the screen reader needs to read “Grade 11 Step 4 61,133; Grade 11 Step 5 63,192; Grade 11 Step 6 65,051…”. But the only way that a screen reader can do this is if the cells for grade and step are marked as “header” cells. This is a basic accessibility test and most automated scanners check to see if tables have such header cells.
The problem? Screen readers like JAWS®, notices that a table like this lacks header cells. It will assume that the first row and first column are header cells. So, a tester using JAWS® may form the incorrect impression that the table is fine. In reality, it has a huge problem because many other screen readers won’t perform this automatic self-correction. And, because it’s easy to catch these errors with automated scanners like those used by many of the plaintiff firms, these kinds of errors can leave organizations easy targets for litigation. Tables are just one of the places where screen readers can overcompensate for poor design. For instance, they commonly do the same for badly labeled forms - another common area of web accessibility litigation.
The solution is knowing when a screen reader is overcompensating for poor design and how to turn these features off or decide to test with another screen reader. Good disabled user testing also requires knowing when the limitations caused by a disability require assistance from another tester. For instance, a blind user can tell when audio descriptions are available for a multimedia presentation, but that doesn’t mean that the audio descriptions will be accurate and convey enough information to understand the video content.
The synergy of Converge Accessibility and Outlook Business Solutions
This is where the combination of Converge Accessibility and Outlook Business Solutions provides a better solution together than apart. By working together, we can update the WebAlign testing scripts to make disabled user testing accurate, repeatable, and thorough. And by combining WebAlign with Outlook Business Solutions’ disabled user testing, organizations can leverage their existing testing teams and become proactive with web accessibility—while also using Outlook Business Solutions’ strategic application of disabled user testing.
Outlook Business Solutions provides accessibility testing that ensures your digital properties can be used by everyone. Converge Accessibility’s WebAlign offering makes the perfect addition to your accessibility tech stack. Find all of the WebAlign details here.