Website Accessibility: Testing (Part 4 of 4)

Part 1: What is Accessibility? Why should I care?

Part 2: Assessing Your Accessibility (What to Fix)

Part 3: How to Fix It?

Part 4: Testing ⬅YOU ARE HERE

During my testing experience, I’ve grown very fond of accessibility testing tools. Not only because it can be hard to put your yourself in the shoes of every possible angle to test for, but also because it can be challenging to determine if the component in question is within the accessibility conformances or not. In this post, I’ll give you some of my ideas, tips, and tools that I’ve collected during my experience with accessibility thus far. Focusing more on the styling and functionality of the site rather than the content.

Gather Some Tools

To make testing a little less intense or complicated, you can download some handy tools for Chrome to help. I have tried a handful of different extensions and kept a couple, Siteimprove Accessibility Checker and WAVE Evaluation Tool, in my toolbox for future use. Though these extensions should not be your only means of determining the level of accessibility, they will give you helpful feedback without having to dig into the code in great detail – let your developer do that!

Other helpful extensions include FreshEyes and Reader View. FreshEyes will give you an idea of how a colorblind user will see the site, depending on which filter you select. When checking here, keep in mind that the color contrast has potential to be more of a concern for a user that is not color blind. You can use Siteimprove along with FreshEyes to help examine this. With Reader View, you are checking to see if all pertinent content is available, as it essentially removes the CSS and JavaScript from the page. If you have content that depends on CSS or JavaScript to display, you want to make sure there is an alternate delivery method available.

I also suggest downloading the NVDA screen reader (for free), as well as looking over the VoiceOver capabilities for testing on an Apple product. Hearing how a screen reader presents the components of the site to a user will allow you to determine if they are getting the best experience possible. If it sounds funny to you, it can be confusing to them. Part of me suggests to get familiar with screen readers, if not already, while another part says not to. Some of the frustration you could experience while getting use to these could lend some insight into how a user interacts with a site for the first time. If you feel frustration building up while familiarizing yourself with the shortcuts and gestures, imagine that as the experience a user may have with an inaccessible website.

The last tool is knowledge. Take a look at some information about different visual impairments to get a better understanding of what users could be experiencing, or what other kind of assistive technologies are used to access the web. If you know someone that may have a disability, impairment, or uses assistive technologies, ask them if they could help in inspecting; real user testing determines the level of accessibility the best.

Put Yourself in Someone Else’s Shoes

So, now that you’ve tested your site with the tools mentioned previously, it’s time to put yourself in someone else’s shoes for another round of testing. For desktop or laptop testing, unplug your mouse and set it to the side. Find a blindfold or some DIY impairment specs—a post for these DIY specs coming soon—and go through the site using a keyboard and a screen reader only.

It might take a few tries to get use to it, but eventually you will be able to identify which areas cause trouble. While doing so, refer back to our assessing post for the questions to keep in mind. Take notes for the areas you find confusing, such as a weird ordering of form fields while using the tab key, to discuss with a developer if further improvements are needed. Include the information provided by the accessibility extensions with the developer as well, to give them specific examples in the code to look over.

I remember a particular lesson in my 6th grade health class, where we went through the different senses and a handful of experiments for each. One of homework assignments that week was to eat dinner while blindfolded. We had to lean on our family for support – to tell us how the plate was laid out using a clock format, mashed potatoes at 12, corn at 2, etc. – and a sort of muscle memory to remember the layout. In a way, that lesson is similar to how a user interacts with a website. Relying on some support, acting as assistive technologies, and muscle memory to help build the layout or placement in a cognitive schematic. With that said, combining the tips and tools I’ve referenced, as well as a general understanding on code semantic HTML in our previous post on (How to Fix It), will give you a great starting point to thoroughly test for accessibility. And with some helpful feedback from real user testing added in, your site will be an accessible champ in no time!

More Tools and Resources!

There are a lot of tools out there and, obviously, some are better than others since they are not all the same. Don’t rely on just one of these tools, because it may miss something that another will not. And although they may report issues, it’s ultimately up to the human perspective to recognize the priority of the accessibility.

Extensions (for Chrome) & Screen Readers

• Accessibility Developer Tools
• OpenWAX
• JAWS
• ChromeVox
• ZoomText

Resources

• Web Accessibility in Mind
• The A11Y Project
• ARIA in HTML