When I meet with a product or development team one of the things we go over is where the common buckets of hurt lie. As everyone knows we want to fix this stuff early in the process because it’s much more difficult to get the sauce off the spaghetti later. Primarily we’re focused on web products since that is the platform where most of our developers are working but many of the buckets also apply to desktop and mobile apps. So here are the top 10 buckets for testing.
Over the years we’ve had a number of folks try out the jQueryUI accessible widgets to check for compatibility and bugs. To make this a bit easier I wanted to provide some guidance about the kinds of information we would need to make the test results useful. In general we use Firefox on Windows with NVDA as our baseline and also give things a whirl on Jaws and VoiceOver. One issue with testing in Jaws is that it attempts to ‘help’ by doing silent repairs of what it finds under the hood, which can both mask bad markup and also introduce phantom errors. NVDA and VoiceOver are both more literal in their interpretation and give a better indication of correct coding. We also deviate to some extent from the jQuery philosophy of trying to smooth over differences between browsers and platforms. While the goal is laudable, in the accessibility world it’s not really achievable without piles of hackery to overcome broken or missing support. The volume of additional code and the extreme brittleness would make these kinds of solutions break the future-proofing of our implementation. So after a bit of debate we decided to go for a correct and best-practice approach which may not always work in all browsers, platforms and AT but should work once full support and debugging of those layers is complete.
Apple VoiceOver screen reader link list
I ran into another accessibility issue with WordPress in how it adds “Continue Reading” links to posts. I started inserting “More” tags so the front page just shows a paragraph and then shows a link to read the full article. This reduces cognitive load as users can skim through what’s new before diving in. Unfortunatly the default behavior of wordpress is to use the exact same “Continue reading” link after every article. This may seem innocuous to some but for a screen reader it not only ruins one of the handy quick navigation solutions, the link list, but it also violates WCAG 2.0 2.4.4 by obfuscating the link’s purpose.
Those of us who work in or closely follow technology access can easily sing the praises of a robust keyboard interface. Of course a large number of people in the “mainstream” audience prefer to use keyboard shortcuts when they know about them. Quite simply, pressing a key combination to print a document is a lot faster than locating and clicking the “Print” button with a mouse. Below is a list of helpful shortcuts for AOL’s media player. Continue reading
I chose the WordPress “Twenty Ten” theme partly because it seemed to make better use of space and, by now, should have all the significant bugs worked out of it. That said, it does seem to have some accessibility issues in the missing alt text on the header image and insufficient contrast in the link text surrounding a post (grey text on white).
AOL has been working with The Paciello Group for quite some time now to produce a set of jQueryUI widgets that have accessibility baked in. While the developer might have to provide a label for the thumbs on a multi-thumb slider or other bits, they generally shouldn’t have to fully understand ARIA and accessibility to get things right. Hans Hillen from TPG has been the primary developer and all his code changes are checked into the jQueryUI 1.9 branch in GitHub. Once the 1.9 version is released to production any developer who upgrades should inherit this work. For now you can either grab the latest 1.9 branch from the Github site or you can play around with our demo page.