A question that has come up on the TLT “A-Team” (that would be A for accessibility) is how to provide a simplified testing protocol. For a while, we’ve been trying to come up with one tool to replace the current accessibility.psu.edu Testing Protocol developed a while ago.
In a recent testing session though, I have to confess that I still fell back to my multiple tool scenario because it actually saves time. I did feel a little better that, at the Penn State Web conference, accessibility guru Glenda Sims pretty much recommended a similar protocol, but with different tools.
I’ll try to explain what my protocol is, and why I think it saves time. I have to warn you though, that it does require some familiarity with HTML. Before that though, I will explain a very 2-step simple protocol which does work, but will take some time.
The Simple Protocol
Based on what the major issues have been, Penn State has been focusing on screenreader users and the hearing impaired. The simple protocol has been:
- Test key pages on a screen reader (no cheating with a mouse!)
- Test all videos for captions. Ensure that audio has a transcript
This is a solid protocol and will find almost all the errors we are concerned about. It will miss some color contrast issues and will not necessarily determine if users NOT on a screenreader can use the material with just a keyboard. It is time consuming and does require some familiarity with a screen reader, but does have the advantage that minimal HTML knowledge is required.
More Complex But Faster
However, I do in fact use more tools, to streamline testing to the main hot spots. Once I got familiar with these, I do find that the process goes much faster.
There are lots plugins and tricks that make Firefox my browser of choice (although Opera is also recommended). One of my favorite Firefox tricks is that you can select part of a page and view the code for just that selection. Very handy for zooming in on tricky areas.
For Firefox, I would install the FAE Toolbar. The FAE Toolbar not only links to some of the tools mentioned below but includes tools to quickly disable image, CSS and other tools.
The first part is to test a “typical” page and the home page on a site. I usually do this with WebAIM Wave. The report not only flags errors, but does a good job of showing you what a screen reader will read out in many areas. Specifically it shows:
- ALT Tags for all images – You can see if they are present and make sense
- Form field labels – like ALT tags, you can see if they are present and make sense
- Location and levels of headers – Proper use of headers is very valuable to screen readers
- Table structure – If your data table is missing header, summary and captions. It probably needs a redesign
The other benefit of WAVE is that you can spot WHERE you need to fix code.
This is a good way to test reading flow in a screen reader. Sometimes floats can put the last thing in the code on top visually, but by disabling CSS you will see the “true order” which is the one screen readers access.
Check the HTML!
If I see a table, image or form, I sometimes just check the code.
Check Color Contrast
An item most reports can’t check is color contrast. There are tools to do this automatically, but I find that my eye can find many of the errors. Black and white – good. Dark navy on sky blue, probably good. Light gray on dark gray? Time for a check.
Verify with a Screen Reader
I still test with a screen reader when the other tests don’t give surefire results. I check things like new tools (VoiceThread, NBC Learn, Google Forms….), anything requiring interaction beyond the usual HTML.
(Actually a lot of “screen reader” testing was actually done by Michelle McManus and Peggy Hoover who are everyday users of JAWS. If you have access to real users, they are your best source of information).
A Single Tool?
A new tool I am interested in checking is FireEyes from deque. This does put all the protocols I discussed above into one environment. But from what I’ve seen, you still have to push a lot of buttons.