Supporting the Clean Markup Plea (10th April 2010)
If CSS had been given the resources wasted on ARIA over the past several years, we could be using proper form controls with all the styling we wanted today. ARIA is an expensive counter-innovation which distracts from Web Accessibility. As such, I support the Clean Markup Plea from Anne van Kesteren.
ARIA in Reality
Claiming ARIA makes crappy code accessible today, like it’s some sort of magic bullet, is false. Non-semantic and counter-semantic HTML which uses ARIA is obviously not accessible in browsers which:
- don’t implement ARIA, such as Internet Explorer 6 (still widespread and locked in, sadly);
- miss out parts of ARIA which the page relies on;
- or have bugs in their implementation.
The ARIA implementations I’ve used in browsers and screen readers seemed like experimental betas. Stability, usability and capability were unimpressive to say the least! This is despite the endless developer blogs and corporate hype written to promote how awesome they are.
External Factors
ARIA is also not a solution when:
- an OS has no way to communicate such features to ATs;
- an AT does not implement such features.
- or a user requirement is not accommodated by ARIA.
Scenarios for Deploying ARIA are Nonsense
- Why would they care about (or even know about!) the ability to add dozens of ARIA attributes, which have no visible effect, to their already spaghetti-like code?
- Why would a budget be increased for this when the company didn’t care about accessibility in the first place?
- Remember, bolt-on accessibility is the most expensive kind of accessibility.
- Where ARIA does get retrofitted, the developers have little chance of getting it right.
Errors by The Paciello Group
Their article includes a section entitled “Aria roles and properties not available in HTML5”. It includes several bulleted lists. (I didn’t review the “all aria-*
attributes” section.)
- Many of these items are available in HTML5, HTML4 or even earlier specifications. That’s confusing.
- Stranger still, these contrary items aren’t marked or indicated as being special.
- Finally, the items which match with the heading are the ones marked as being abnormal! (They have a plus sign after them.)
Out of the 60 items introduced by that heading, only 30 are actually “features not considered to be available natively in HTML5”. By The Paciello Group’s own assessment, half of the items directly contradict to the heading they chose to introduce them!
Overstatements and technical errors seem habitual amongst ARIA fans, from what I’ve seen.
Open-and-Shut Case
The item named definition
has the plus sign suffix, marking it “unavailable”. Yet this is amply provided by both the <dfn>
and <dt>
elements in HTML4. It even links to the part of the ARIA specification which points that out!
As such, more than half the items in those bullet lists directly contradict the heading chosen by The Paciello Group. So why are they introduced that way?
Unrelated but Interesting…
The HTML used by The Paciello Group for the image of a Search Mail button has 3 typos in the alt
text and is not a really useful description of what the image shows:
<p><img class="alignnone" src="…" alt="serach mail button" height="30" width="81"></p>
I suggest this:
<p><img src="…" alt="‘Search Mail’ button has silver gradient background surrounded by a thin, dark border with rounded corners." height="30" width="81"></p>
(There seem to be no styles associated with class="alignnone"
so I removed that as well.)
The alt
text for the image of a Create a filter link is completely empty:
<p><img class="alignnone" src="…" alt="" width="80" height="16" /></p>
I suggest this:
<p><img src="…" alt="‘Create a filter’ link using small, blue underlined text." width="80" height="16" /></p>
Hype as a Widespread Problem
Such noise creates ARIA’s unwarranted popularity amongst forward-looking developers. Developers read the overstated headlines and skim the erroneous lists, leaving with (deliberately engineered?) false impressions.
Eerily reminiscent of XHTML hype, which still lingers throughout our industry.
Effective Use of Resources
I’m also bemused and saddened by the way ARIA work continues to get funding and grab headlines. Especially since the real solutions continue to be starved of the resources they need.
The solution to making new patterns accessible is to create smarter ways for people to do them that are automatically accessible and do not require annotation with WAI-ARIA.
Anne van Kesteren
An example of that might be automatic table accessibility. Which has since become part of HTML5, improving upon the relatively vague strategy for table header association in HTML4.
The “smarter ways” have already proven feasible and they scale to the whole web.
Responding to Comments (11th April 2010)
To Matt May
It could equally be said that the “good” (ARIA) is being the enemy of the “perfect” (better styling of form controls and better interactivity in HTML). ;)
To Shelley
Comparing kilobytes of JavaScript and the resulting DOM with a (currently hypothetical) HTML+CSS equivalent would indeed make the former look like spaghetti code. To my mind, at least.
More to the point, the example of Gmail’s simple image button and simple text link given in The Paciello Group’s article are completely possible and widely compatible using straightforward HTML+CSS. Tab describes them accurately, imho!
And that’s a best case scenario for the scripting side of things. From my experience of doing WCAG audits and poking my nose into the source code of hundreds of websites during HTML5 research, JavaScript controls were usually bespoke kludges which only supported IE6. That may be changing but remember the The Long Tail effect and Legacy Content Problem.
jQuery UI is a branch of jQuery, as I understand it. They are targeting “Full support for Accessibility WAI-ARIA [at the] end of 2010”. So the current version doesn’t have that. Not sure if the main project has it at all. Perhaps you were thinking of Dojo?
To John Foliot
The sentence from me which you quoted begins with the alternative. Anne’s blog entry contains it, too. Which you also quoted.
My notion of “resources” includes all forms of time, equipment and skill. Very much including that of volunteers. In case you aren’t aware, I gave a year of (very) part-time voluntary effort into the area of HTML5 accessibility. 6 months of more sustainable effort was generously funded by Mozilla Foundation. Some trans-Atlantic travel for myself and several others by Google, too.
Much of (if not all of?) WHATWG started out as volunteers. They helped me out a lot, both remotely and during a couple of W3C conferences. Funding and support makes voluntary effort far more sustainable.
That alt
text is correct for that context. The purpose of those cropped screenshots is to convey the effect Gmail is going to such lengths to produce. Even a person blind from birth stands a good chance of relating to most parts of the description.
- Gradient:
- Cross a crowned road.
- Rounded corners:
- Touch the corner of most household objects.
- Silver:
- A clean and precious material with a smooth, cold surface.
To Various Others
Stressing the “it works today” angle to support ARIA is backwards. CSS could have moved more quickly, possibly giving us stylable of form controls “TODAY”, if ARIA hadn’t been sucking time and skill out of the web standards effort for several years.
ARIA has merely held up what could have been possible “today”. Let’s move past that now. Let’s put the time and skill into the real solutions, otherwise they might never happen.
Responding to Alastair Campbell’s Blog Entry (21st April 2010)
I’ve posted this comment to his blog but it hasn’t shown up right away:
My reply got rather long. I blogged it so I can structure and correct it more easily.
The notion that “these things take time” is precisely why we should have started on the better solutions several years ago, so that they would be ready today. Instead of starting ARIA. It was a mistake to put so many eggs in that short-term basket. (If you see what I mean.)
I suggest that we end ARIA as soon as possible and resume doing web accessibility properly.
Real solutions include (but are not limited to) CSS forms, HTML5’s new form controls and direct support for common scripting patterns in ATs. These could have been progressing quickly if they’d had the investment ARIA enjoys. They could have reached the stage ARIA is at now. See what I mean?
ARIA redirects attention, time and skill away from better ideas whenever they are raised. Just as you’ve done; just as happened in the comments on Anne’s blog; just as happens within W3C and around the web.
There are finite resources and they aren’t going towards the right work. That hinders it from getting started. Any which does start is not sustainable. ARIA is hogging the limelight to the detriment of innovation and progress.
ARIA still isn’t Ready
Yes, the plan is to make sure ARIA and HTML5 work well together. Right now I’m waiting for ARIA to be complete […] Once that is cleared up, I expect HTML 5 will give a list of conformance criteria saying where ARIA attributes can be used and saying how they should be implemented in browsers.
Ian Hickson
Heh, the irony of using that quote to support ARIA. It states HTML5 is still waiting for ARIA (the specification) to even be ready for consideration!
Pace of Progress
- ARIA isn’t a W3C Recommendation yet, same as HTML5.
- ARIA has been worked on within W3C far longer than HTML5.
- ARIA has a minuscule scope compared to HTML5.
- ARIA has far less political resistance within W3C than HTML5. (It’s hard to imagine anything having more!)
- ARIA works in private, partly on the pretense that this makes the work go faster and better.
- ARIA is define less precisely than HTML5. (Partly why it isn’t considered “complete” enough for consideration.)
Henri’s ideas for the integration of ARIA into HTML5 was one of the things we discussed at those PFWG meetings. (As well as over lunch and in corridors, you know how it is.) More than 2 years ago.
Text last updated: 2008-03-31 by Henri Sivonen.
Describing ARIA with words like “quickly” when you have facts like this is…staggering. I’m trying to point you towards them. Once you see through the ARIA hype, the ways forwards for web accessibility have no requirement for it.
(More relevant still may be Simon Pieter’s ARIA proposal, written in the style of a WHATWG specification. Again, notice “Last Update 19 November 2007” at the top. There’s an e-mail to announce it, linked to from HTMLWG Issue 14.)
We could have started on the better ideas years ago and be enjoying them today. People like Simon and Henri could have been researching ideas, attending meetings, participating in mailing lists and writing drafts about the ways that will work instead of what they did to try and help ARIA.
My Suggestion
We can’t change history. But we can stop this big mistake, ARIA, from getting any bigger.
Let’s do web accessibility properly, from now on.