Evaluation and Testing: Accessibility for Everyone: Long Form Book Review

As seen in my last few entries, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

EVALUATION AND TESTING

Laura's main point of this chapter is that we can do all of the work, follow all of the guidelines, dot all of the 'i's and cross all the 't's and still fall well short of the intended goal if our implementation doesn't actually help our end users achieve their aims. Having been part of several Accessibility initiatives over the last five years I can attest that unanticipated things show up in testing or require the original hypothesis to be reconsidered.

That's great, so what is suggested? Well, for starters, make a plan. Whether that be a formal test plan or a series of conversations ons specific topics, the point is that there are a lot of criteria to be considered when looking at an Accessibility issue and creating a remedy for it. What approach will you use? How will you gauge progress? How will you document the testing progress? How will the testing results and recommendations be fed back into the development process? These are standard questions for any software tester, and how they are handled will vary between organizations, but they all go through this process in some manner if they wish to be successful.

One way to get a head start on looking at Accessibility issues is to become familiar with the WCAG standard. Different countries have their own standards, but WCAG is intended to be International, and as such will have a broad range of areas to look at. At times a local standard has some additional details that are relevant to that area, but usually looking at WCAG and meeting the requirements there will most of the time satisfy local requirements. The few that don't can be handled on a case by case basis.

The best test strategy is to literally use the product in the way that the intended customer will use it. If you need to rely on a screen reader, turn your screen off, or even better, find a dark room and do it so that you have limited ability to see the target machine. This is an example of persona testing taken to the next level, but I can attest to the fact that it is effective.

If you have the ability to participate in code reviews you have a chance to help shape the product at a fundamental level. Even if you don't, getting together with the programmers during the story workshop to discuss requirements can go a long way in helping to set up the necessary processes to ensure success. Also, a lot of the structural elements for Accessibility exist in the HTML and CSS, as well as other web technologies. That means that they can be looked at and confirmed to exist with automated tests. Still, don't be lulled into thinking you can automate all of the testings, as a lot of Accessibility comes down to the user experience. As of yet, that's proven to be a very tricky area to put automation into. For now, it still requires an empathetic human.

There are lots of tools available to the programmer and tester looking to validate their Accessibility work. Laura includes several that I would also consider excellent, such as:

W3C Markup Validation Tool
WebAim WAVE
Color Oracle

Laura has a much larger listing in the Resources section of the book.

KEY TAKEAWAY

The best way to test for Accessibility issues is to actively encourage and set up opportunities to test with people that actively use Accessibility software and devices. If that's not possible, then persona based testing is required and will have to stand in as the next best thing. There are lots of avenues and ways to test, lots of available tools, but ultimately it all comes down to one thing; can your intended audience of your product use it effectively? If there is a need for assistive technology, can that technology help provide a comparable experience for all of your users? If that sounds like a tall order, that's because it is. As I stated earlier, and as Laura also makes continuously through the book, we can work on Accessibility techniques but they don't amount to much if our users are frustrated in their goals. The best way to help ensure that doesn't happen is to test our implementations often.