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

Comments

1. Gee, no need to wax that lyrical about it Good to see you and great talk!

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

3. Hi Steve.
   Thanks for posting the slides. I thought the talk was great and I was glad to see it generated quite a number of questions when you’d finished! Like you, I was really pleased that Nate Koechley and John Resig were enthused with ARIA and about getting it implemented in their respective JS libraries which would be really beneficial for developers and end users alike.
   Good to see you too!
   Andy.

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

5. hi Marjolein,
   for the purposes of the demonstration as I was trying to provide simple examples, I left off the state info in the alt. In practice I would recommend that this is included, for graceful degradation purposes as aria-pressed is not yet well supported. Once it is, the state information would be better included using aria-pressed, as it maps onto the appropriate accessibility API state property, like the native HTML checked attribute, while the alt attribute maps to the MSAA accessible name property which is not designed to include state information (refer to ARIA User Agent Implementors Guide).

6. 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?

7. hi again Marjolein.
   Take the example of a HTML checkbox. it is a control that has 2 states – checked or unchecked, this is represented visually by a box with a tick or cross for checked and an empty box for unchecked. The state information is conveyed using the checked attribute. WAI-ARIA provides a method to convey state information for a button that has multiple states. This is not only mapped onto MSAA, but also linux and MAC accessibility API’s (i used MSAA as an example). In the example we are discussing, it is one form control , a button (input type=”image”), which can through scripting have visually represented states (selected/ not selected), not 2 separate images.

   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”. Even with the information included in the alt, the user still gets consistent notification of state correctly conveyed/announced as per their assistive technology when WAI-ARIA is added.

   It may well be that I am not making myself clear. Have a look at an example of toggle buttons that don’t use images: ARIA Button example.

8. 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?

9. Hi again marjolein,
   I seem to be missing the point here, I have not argued that trad methods shoul not be used. As i have said the example that you have taken issue with, is one i left off information from the alt to empahsise state information provided using an ARIA property. 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 included in the alt in this case.

   “instead of replacing parts of HTML and CSS, ignoring browsers that don’t support it and hollowing out WCAG?”

   I don’t see where I have advocated this, and if that is what you have interpretated my presentation as meaning , then I will take this opportunity make it clear, this is not what I am advocating.

10. 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 http://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.

11. Hi again marjolein,

    suggests that proper alt text could be replaced by “superior” ARIA.

    In the future i hope very much that the use of the alt attribute to specify state information is no longer required as it is a less than optimum solution brought about by the paucity of native HTML elements and attributes that are available to provide correct role/state and property information using Accessibility API’s. Would you not agree that providing state information via an attribute that maps to the state property in API’s is preferable to stuffing it in the alt? It would be better still if the developing HTML5 specification provided native elements/attributes to cover all the features in WAI-ARIA, but that is unlikely to happen.

    I am well aware that WAI-ARIA is not a magic bullet that sweeps away the need for the other building blocks of accessible semantic markup. And I definitely agree that more good examples are needed.

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

13. hi Roger, I think that a podcast will be available from the @media 2008 site at some point. There are also some blog notes of the presentation taken by Gareth Rushgrove.

14. Hi Steve

    Thanks for posting your presentation. I really enjoyed it.

    Antonia

15. I’ve seen your presentation at @Media and found it really interesting.

    I’m just wondering, what is the relation towards WCAG 2.0?
    Wil WAI-ARIA be part of WCAG 2.0, or is it apart because it’s more about RIA’s then normal HTML?

    Thanks for your answer!

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

17. Thank you for your explanation and the links, Steve

    I’ve installed FireVox and found your examples useful. Do you know any good sites who already use WAI-ARIA?

Comments for this post are closed.