WAI-ARIA, it’s Easy – @media 2008

Steve Faulkner says:

Thanks Christian, good to see you again too. I should also say that it was good to meet up with Patrick Lauke, Henny and Andrew from RNIB, Lachlan and JGraham from the HTML working group, Ian Lloyd, Kath Moonan, Martin Kleihm and all the other people I had an opportunity to talk with.

Marjolein Katsma says:

Great presentation, but one thing puzzles me: the “button highlight” example.

In your example there are two different button images, apparently top indicate state; but both have an identical alt text. Surely that’s the actual problem here?

An alt text should give a functional alternative for the image — and since the function is ‘state’, the alt text should make that state clear. So when you change the alt texts to indicate state, where’s the need for ARIA in this example? I don’t think ARIA’s role is to repair essentially broken HTML.

Marjolein Katsma says:

Steve,

I’m afraid having trouble understanding this. Shouldn’t we start by writing accessible code – regardless of whether it’s provided by AJAX or server-side scripting or static HTML? Two different images that are not decoration simply should have different alt texts, or it fails accessibility rules according to WCAG. And that is platform-independent, while MSAA (however useful it is) is a Windows technology.

Can (or should) ARIA “make” accessible what according to WCAG clearly isn’t? I don’t think such a contradiction should exist, and a document that fails WCAG to begin with should not be deemed accessible because ARIA was used on it.

So let’s assume the two different images do have different alt texts, as they should (regardless of origin of that code fragment). What does ARIA add then? Why (or when) would it be needed?

Maybe your slides just miss some context that is essential for understanding your point. Is there a version with speaker notes that makes this clear?

Marjolein Katsma says:

Steve,

The whole point of ARIA is to make accessible that which cannot be made accessible using traditional methods. As I said in practice i would recommend including the state info in the alt as that is best supported at the moment, but a superior method is via a dedicated state property such as “aria-pressed”.

My point is that an image (including an image button as in input type=”image”) requires an alt text that provides a functional alternative when the image can not be seen. So it can be made accessible using traditional methods, simply by making sure that the alt text indicates the state (which is the function of the image). This will work with any browser, including text-only browsers that don’t support JavaScript (let alone ARIA).

I do not have a problem with using ARIA to add an additional layer on top of plain accessible HTML. My problem is with the suggestion that there is no “traditional” method to make it accessible in the first place. The ARIA markup may be useful, but does not negate the need for accessible markup in the first place, which is perfectly possible in this example.

The “toggle button” example without using images actually makes clearer case for ARIA, because in that case there is no clear “traditional” method to indicate state (but only because a title attribute is not guaranteed to be read — it would be helpful anyway). This might even make a case for using an image button instead of a HTML+CSS-only one for toggle buttons, because an image actually has an alt attribute that can — and should — be used to indicated what the image’s function here is: to depict state.
(I note that the toggle buttons you point to actually have totally unhelpful title text “Text Formating Controls 1”, only on the UL level — surely there’s room for improvement here, too.)

Progressive enhancement is building with three layers HTML (structure) -> CSS (presentation) -> JavaScript (behavior). Shouldn’t ARIA provide layer four on top of that, instead of replacing parts of HTML and CSS, ignoring browsers that don’t support it and hollowing out WCAG?

Marjolein Katsma says:

Steve,

Well, maybe I was missing the point, so thanks for your clarification! Clarification is what I was after.

In a previously published toggle button example I have included such info in the alt as i thought that somone may actually copy the code and wanted to ensure that the state info was also inlciuded in the alt in this case.
Now that is a far better example — in fact the first really good one illustrating a toggle button. It’s far better simply because it is properly marked up and accessible code in the first place, showing also that different browsers with different AT all actually get the basic info about state from the alt text. Now it is clear what ARIA actually adds to that, added as a fourth layer on top of the three layers already present.

I don’t see where I have advocated this …

Not advocated, but (to me at least) certainly suggested by statements like

…the state info in the alt as that is best supported at the moment, but a superior method is via a dedicated state property such as “aria-pressed”.

That — in combination with examples that don’t have proper markup — suggests that proper alt text could be replaced by “superior” ARIA.

It’s great to advocate ARIA. I’m all for that.
But I’d like to make a case for only using examples for that that already use proper, semantic and accessible markup, thus demonstrating how ARIA can add an extra useful layer to that, instead of starting with markup that doesn’t have those properties by itself, and then with the example suggesting that doesn’t matter, because ARIA is “superior” anyway.

My apologies for seeming to be picking on you, but that was triggered by one such example with bad markup. I browsed through collection of examples at https://test.cita.uiuc.edu/ you pointed to but unfortunately that has many more examples of essentially bad markup, “made good” by adding ARIA — the resulting message being that with ARIA you no longer need to worry about semantic and accessible markup.

ARIA needs more good examples with proper markup, do demonstrate what it adds. I guess there’s a big job for the EOWG here.

I’ll climb off my soapbox now. 🙂

Roger Hudson says:

Hi Steve,

The slides look very interesting and I am sure the talk was equally good – but unfortunately being from the other side of the world I was not able to be there. Is the audio of the presentation available online (or speaking notes).

Thanks again
Roger

Antonia Hyde says:

Hi Steve

Thanks for posting your presentation. I really enjoyed it. 🙂

Antonia

Steve Faulkner says:

Hi Rosely, WCAG are guidelines for making web sites accessible, while WAI-ARIA is a specification that introduces new mechansims for adding accessibility information to other languages such as HTML. The relationship between WAI-ARIA and WCAG is that developers will be able to use WAI-ARIA to provide better solutions to accessibility issues such as dynamic content updates. Whether these will aid conformance to the WCAG guidelines depends very much on the context in which they are used and the fallback mechanisms that are implemented in conjunction with ARIA. So if an ARIA solution is used in a closed environment such as a university or corporate network, where the user agents support ARIA, then it would be sufficient to conform to the relevant WCAG criteria. If the same solution was deployed in an open environment where ARIA support is unknown, then ARIA alone would not suffice.

I probably haven’t explained it well, but information about conformance in WCAG 2.0 and in particular the section regarding accessibility support may help clarify it.