So I haven’t had any first-hand working experience on web accessibility testing. I’ve read about it in passing, and once I attended this weekend testing session that tackled the subject. In my previous company where I did a lot of functional web testing, I recall some standard test cases that were related to usability or accessibility. This week though, the topics of accessibility testing and WCAG 2.0 came up, and I had to google a bit on the subjects.
One of the interesting things I found is this blog post on how expensive is accessibility. And what the writer, Karl Groves, said makes sense — that if it’s already part of how you do things, then it comes at no extra cost. And inversely, if it’s something you haven’t factored in at all, then pushing for accessibility would require changes and those changes would undeniably entail some cost.
Now I googled WCAG 2.0 and found really looong references. There’s a quick reference page, but seriously, that page felt anything but quick. In another post by the same person:
What if I told you that the WCAG 2.0 recommendation by the W3C is 36 pages, printed? In addition, “How to Meet WCAG 2.0” is 44 pages and “Understanding WCAG 2.0” 230 pages. Not only that, but the accompanying Techniques and Failures for WCAG 2.0 is 780 pages, printed.
That’s a bit daunting!
But thankfully, he also shared a post on the 6 simplest web accessibility tests anyone can do. And the Web Accessibility Initiative (WAI) has a reference on easy checks for web accessibility. These could be a start and could be things we start looking for in our web testing projects even though we weren’t really asked to do accessibility testing. It’s a chance to add value. Let’s check these out:
To a lot of folks, drafting a blog post with the unaided eye might seem like a very mundane task — no biggie, easy as pie! As for me, as I type these words, I cannot read what’s being displayed on screen thanks to my less than perfect vision. I usually wear contact lenses with PWR -4.00 and so without them my face would have to be around a hand span away from the monitor for the text to be readable. Using my browser’s zoom function isn’t really of much help. Even at maximum zoom, at my usual resolution and with the monitor at arms’ length, the text still looks blurred and the site’s layout gets badly compromised.
For some, I guess an option is to use screen readers. And last Sunday, that (and accessibility) was actually the focus of the WTANZ session. For the session, I used a Firefox add-on called Firevox and one of the built-in apps in Windows called Narrator. Our mission was to go to the weekend testing website and log in, with posting a comment reply as a bonus — without looking for most parts.
One downside of Firevox is that its keyboard shortcuts seemed to have been in conflict with my other add-ons. So to enable it, I had to look on screen to find and click the corresponding icon. Once enabled it went on to read text from the website including some stuff which sounded like css properties. It also gets triggered by mouse actions so whenever I move my mouse around, it starts reading the section where the pointer is at. I suppose it does this by design but it was awfully distracting whenever I moved the mouse pointer by accident.
As for Narrator, I wasn’t really able to use it as a screen reader although I think it could function as one. It’s use for me during the exercise was for telling me where the focus was as I shifted between windows or between fields using the keyboard. Sometimes it gets annoying though since it seems to repeat some stuff over and over again.
Some other things:
- I found myself inclined to use the keyboard instead of the mouse. This means shortcut keys and correct tab ordering come in very handy.
- It’s also helpful to have a default focus on first field to be most likely used — e.g., Search text box in Google, Username text box in wordpress.
- The field descriptions proved to be quite useful. — For Narrator, it reads out these descriptions when the focus is on the field. Without these descriptions (as in the case of the post reply form), I couldn’t easily tell when I could actually start entering inputs. Downside though is the Narrator took around 2-3 seconds before it read it out loud.
- Breadcrumbs are not screen reader friendly. Sometimes I just wanted to know which page I was at but the reader would go on to read the entire trail.
- Same thing with some of unnecessary links on top of the page (as pointed out by Oliver). These aren’t screen reader friendly as well.
- An interesting point raised during the discussion was that it would be helpful if there was a b.<whatever.com> version similar to the m.<whatever.com> for mobile sites OR some way to tone down the site content to be more apt for screen readers.
- We thought ALT text would be read by the screen reader. I tried Firevox on xkcd but the ALT text wasn’t read.
I guess what Marlena said during the discussion sums it up best: “This was, ironically, eye-opening.”