The Acid tests are a prominent form of Web Standards evangalism. This page is part of an experiment about what an accessibility oriented Acid tests might look like.
This effort was inspired by Steve Faulkner's sterling work on testing the accessibility support in browsers, specifically his article on form control handling. This page is an alternative rendering of his test page.
My current goal is to try to make the accessibility problems visible and ugly. If the particular technique results in something missing, I shrank, grayed, and struck out the corresponding object. If something is repeated, I repeated it, made it larger, and colored it.
I think in a real A-Acid test, one would make a normal page using the broken features. Indeed, my current thought is that "making the breakage visible" could be a generally effective evangalism/validation tool. Visualizing the accessibility behavior addresses several issues:
Please let me know what you think! Email (bparsia@cs.man.ac.uk) or Twitter (@bparsia) are fine.
Probably the most interesting intial comparison is between this any any column of Steve's test results table. The table is good for comparing things and getting an overview, but it doesn't make clear the experience, and how crappy it is. One great thing about the Acid tests is that you experienced the pain of failure directly.
In plain mode, the lil geek code bit indicates how each engine did on the test either + (full support), * (partial support), or - (no support). Thus, you can see that test 8 is the best supported.
Click on the name of a configuration to see how the page would sound (sort of) to someone using a screenreader.
| | | |
label wrapped with text before and after input
label wrapped and for/id with text before and after input label wrapped and for/id with text before and after input
label wrapped and aria-labelledby
The stylesheet switch code was taken from this About.com tutorial.