April 2010 in the Life of Ben (Blog)

  1. January
  2. February
  3. March
  4. April
  5. May
  6. June
  7. July
  8. August
  9. September
  10. October
  11. November
  12. December

Lost My Wallet (29th April 2010)

Left it in Bedford Square the previous day. Although I found it again, all the money and anything which looked like credit cards had been stolen. Cancelled my bank card over the phone. Thankfully they were able to authenticate me based on lots credientials I knew. (New card was dispatched to me and arrived a few days later.)

Not my 11th Blood Donation (23rd April 2010)

Went to the West End Donor Centre in London in order to work more hours. Sadly I wasn’t allowed to donate since my blood iron level was 133 instead of 135 or higher.

Possibly affected by my change in diet. At lunch over the past few weeks I’ve tended to eat a jacket potato with side salad. A BLT was my most common choice before my previous donation.

Contrary to the URL standard I set last time, I used blood-donation by intuition. Corrected it to gave-blood before the entry went live, so no redirect was necessary.

Inflated Car Tyres (11th April 2010)

Today I used the little compressor to check and inflate all 4 of my car’s tyres. Each was at about 29psi.

After much searching I found a sticker where the door latches onto the door pillar. It states they should all be at 31psi. That is now the case.

First time I’ve done this. Got a bit tangled up with the electricity cables and air hose. Managed to stay on my feet and protect the paintwork, though!

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:

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:

Scenarios for Deploying ARIA are Nonsense

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.)

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.

Cross a crowned road.
Rounded corners:
Touch the corner of most household objects.
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

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.