Full Transcript Below:
This is the Accessible.org Podcast. My name is Kris Rivenburgh and today we’re going to talk about user testing.
Having your website tested by people with disabilities, particularly those who use screen readers, is extremely beneficial to you, both from a technical and legal point of view. In today’s podcast we’ll break down all of the ways you win.
First, user testing is like having a second, more practical audit that complements your technical audit and/or remediation efforts. It’s one thing to remediate a website to conform with technical specifications and guidelines such as WCAG 2.0 AA or WCAG 2.1, it’s quite another to have people who utilize the accessibility implementations look over the website.
User testing truly provides a unique point of view that helps uncover potential weaknesses and barriers on your website that may otherwise not be found in an audit.
Second, legally, what better of defense can you have to a lawsuit than being able to say, we have had our website independently tested by multiple people with disabilities, and they have reported no major obstacles in accessing information, browsing products, creating a user account, going through our check out, etc.
When we look at what’s going on with website accessibility lawsuits, we typically have a plaintiff who is blind claiming they have difficulty accessing or engaging with multiple elements of a website.
With user testing, you can very likely A) catch and remediate any potential issues and B) rebuff claims of inaccessibility through documented independent testing from people who are also blind or visually impaired and who regularly use screen readers.
One thing that’s important to note is just because you have two people who happen to be blind, it doesn’t mean that they shared the same experience or same point of view. In many respects, strong feedback reporting no significant encumbrances to access or engagement on your website, app, etc. from real users with disabilities is more important than conforming to WCAG 2.0, or 2.1, because this is getting back to the essence of the Americans with Disabilities Act: effective communication and the full and equal use and enjoyment by everyone. If we can accomplish this with our digital offerings, we are not discriminating.
And obviously we want to bold, highlight and circle any user testing in our web accessibility policy as this can potentially be a difference maker and whether or not a plaintiff’s law firm decides to send a demand letter. User testing is instrumental in showing genuine, ongoing commitment to digital accessibility. Another consideration: getting testing from people with different types of disabilities is optimal.
Ideally, and depending on whether our website or app has audio and/or provides for voice input, we want to have feedback from people with auditory impairments, cognitive impairments, learning impairments, neurological impairments, physical and motor skills impairments, speech impairments, and visual impairments. Lawsuits most often feature a plaintiff who is blind or visually impaired and uses a screen reader.
So if we can get testing- if we can get testing from people who actively use screen readers, that goes a long way – at the very least, in preventing lawsuits and providing accessibility for the blind and visually impaired.
Now, obviously, I encourage you to seek out testing from people with all types abilities disabilities to create an even more robust digital experience, but we have to do what we can at first and/or what we can afford- not everybody has the budget to afford all types of user testing. Obviously, that’s optimal, but we start with where we can and we build on that going forward. The important part is that you get started somewhere and you build on that momentum and you don’t stop once you’ve started. A few notes on testing.
First, it’s great if you can get feedback from different environments. To extract the most value from user testing, you’ll want to get feedback from users across multiple assistive technologies. So primarily the most popular screen readers: JAWS, NVDA, VoiceOver and maybe even Narrator. But the first three are the big three.
Different devices: so desktop, tablet, phone. Different device manufacturers: Apple, Android. Different browsers: Chrome, Firefox, Internet Explorer 11, Safari, etc.
User testing doesn’t have to include every last screen reader, browser, and/or device, but you will want to gather data from multiple angles as well as get documentation on exactly what has been used while testing your website.
So you don’t have to get every one of those down. You want to get the most popular ones, but it’s good to not just test with the same environments over and over again.
Now, when it comes to testing frequency, when and how often you test is up to you as the website owner. I recommend testing after remediation for WCAG 2.0 AA so that you’re working on top of your accessibility audit and getting feedback that hasn’t already been contemplated.
So, ideally, this is something that compliments your audit, but the timing could be different, depending on who you are, what your objectives are and maybe your website – maybe there’s a specific situation, but I think, in general, the best course of action is to get it after your website has been audited and remediated.
After that, the frequency of which you test- at which you test is up to you. If you are a bigger entity, then you’re going to want to test more often. That’s just generally how it’s going to play out. For websites that are constantly changing and updating, you’ll also want to test it higher intervals.
For other entities, for smaller businesses, I think a yearly review is a good default frequency. If your website is static, you can rely on your original testing so long as the ongoing legal standard remains the same. What I mean by that is right now you basically want to conform to WCAG 2.0 AA as much as possible.
However, down the road, the de facto standard, maybe 2.1 and 2.2 is actually going to be rolled out soon – if that isn’t enough, so, but right now most people are trying to catch up to 2.0 AA. And really, that’s what’s in plaintiffs’ complaints is 2.0 AA – any complaints that they’re listing, they’re all issues that could be found as violations of WCAG 2.0 AA – those kind of failures are what they’re looking at, even if they do reference to 2.1 in current lawsuits.
And that is it for today’s podcast. If you would like help with user testing, you’re welcome to email me at email@example.com for more information and, of course, to learn more about web accessibility products and services offered, you can go to accessible.org.