Everything but content is an enhancement.
Heydon Pickering, “Inclusive Design Patterns”
Last fall I had the pleasure to see Heydon Pickering speak at the #a11yTO conference in Toronto. He was not only an entertaining speaker but I also learned a ton listening to him. After the conference I got a copy of his book Inclusive Design Patterns and it was, to put it simply, eye opening.
In the book, Heydon walks through several basic and common patterns we see all over the web — from paragraphs and the document itself to filter widgets and registration forms — highlighting common mistakes people make and the better way to do things.
The very instructive part was that, really, this stuff isn’t hard. I first learned HTML in 1996 (give or take a year), back when tables and frames seemed like a reasonable way to construct a layout. It’s safe to say that I’ve learned better methods since then. Nonetheless, if all you’re going for is something that looks good, it’s still very easy to write crappy HTML. Semantics are actually important, and what you see in the browser as a sighted user is really just the tip of the iceberg.
This creates a whole new dimension to what we could be considering when testing web apps. Even if you think that accessibility or inclusivity aren’t important quality factors for your site or app per se, Heydon reiterates again and again that inclusive design benefits everybody by making things work in predictable ways, the way they were designed to work. The book is filled with examples that are all surprisingly simple for what they do. Filter widgets, accessible registration forms, collapsible menus, and a dozen other interfaces are actually simpler to write this way than to hack together with components that aren’t meant for it. Once you start to know these patterns, spotting unnecessary hacks (and what bugs they’ll inevitably introduce) becomes much easier.
He also provides references to several tools, like forceFeed, TRAY readability, a cost to download estimator, and others, that can be used to evaluate sites for inclusivity.
The last chapter introduced the concept of “Test Driven Markup”, which was particularly noteworthy for me as a tester. Heydon makes the point that CSS can be used to test HTML by selecting for noninclusive patterns:
[undesired pattern] {
border: 0.5em solid red;
}Each CSS selector is effectively one test, saying “this should not exist”. One simple example he gives is that only <li> elements can be in lists:
ol > *:not(li)::after,
ul > *:not(li)::after {
border: 0.5em solid red;
}The a11y.css bookmarklet is already set up to highlight accessibility errors like this, including adding error messages about why things are problematic, and his own REVENGE.css does something similar. Of course, It’s a simple enough technique that it can be extended to highlighting any patterns particular to your app. Any tester or developer working on a web app should have this, or something like it, on their bookmark bar. No need to set up or run any fancy test frameworks (although it’s not a bad idea to do that too, so that accessibility issues can fail in your pipeline).
Especially if you’re new to web or accessibility testing, I recommended getting your hands on this book if you can. Now that I’ve read it, I really need to redo this blog template.
Leave a Reply