Accessible Web 2.0 Applications with WAI-ARIA

by Martin Kliehm

14 Reader Comments

Back to the Article
  1. Reading the article I didn’t find out the advantage of using WAI-ARIA over building accessible pages the “traditional” way. If you structure your page using the normal XHTML elements and if you use meaningful alt-attributes and so on, people with disabilities can already navigate your page. And this is also in line with building clean XHTML and pages accessible for search engines. WAI-ARIA seems to be an additional task “only” improving accessibility and not improving the rest of the website. Instead it only complicates things (at least at this time) as the article explained.
    Copy & paste the code below to embed this comment.
  2. Many current web applications are being built with toolkits such as Dojo that do not use standard (X)HTML user-interface widgets. This reflects both a desire (right or wrong) to be able to create a consistent widget look across platforms and browsers /and/ the fact that many widgets, such as tree controls and live regions, have no standard (X)HTML form. So it’s good that we can make custom widgets accessible, even if building new widgets into new (X)HTML versions and styling options into new CSS versions is a better long-term solution for most widgets.
    Copy & paste the code below to embed this comment.
  3. It’s not progressive, and it’s not an enhancement. Although it’s true that devices outside the limited browser/AT combinations that support this won’t be negatively affected by the attributes themselves, they will be affected by the lack of functionality. If we build applications that rely on this stuff, we’re cutting down our target userbase even further - Opera and Safari are gone, as are older versions of Mozilla browsers, as are (more importantly) other readers, like Hal and Supernova, and older versions of JAWS and Window Eyes (remember that readers are very expensive, and we can’t just expect users to upgrade, in the way we maybe-can for browswers themselves; and the technology that makes this work is a fairly recent implementation). By further implication, if we rely on this approach we’re also cutting out the possibility of a non-scripted interface - if we can’t do it with forms, we’re precluding that right from the start. So this is not progressive enhancement at all - it’s not progressing from a basic foundation, it’s merely force-raising the technology bar even higher (as if Ajax itself isn’t already doing that enough!), and doing so using an unproven and non-compliant technique. I think this is a fascinating idea, and may turn out to be exactly the right approach to solving the accessibility issues arising from the rush toward RIAs. But this certainly not suitable for any kind of real-world useage now, only for experimentation.
    Copy & paste the code below to embed this comment.
  4. I agree to James that this is not the best way to add accessibility to web pages. We should stick to the standards that are in place and that do work. Nothing against innovation (not at all), but this seems to me like a big step backwards. There are many readers available that work ok with structured XHTML. Why reinvent the wheel?
    Copy & paste the code below to embed this comment.
  5. WAI roles can be used to enhance DHTML widgets with accessibility information. It’s true that this is an experimental technology and the spec is not finalized (same as with XMLHttpRequest and CSS 2.1). However, adding role information shouldn’t necessarily render those DHTML widgets less usable in user agents that do not support WAI roles, and doesn’t in any way preclude offering a non-scripted alternative. For example, you could dynamically replace a traditional form interface with fancy DHTML widgets. WAI roles will soon be used, through the IAccessible2 and AT-SPI accessibility frameworks to be supported by future Firefox versions, by (at least) future versions of Window-Eyes, JAWS, NVDA, Orca, and Fire Vox. That list includes a free option for all major desktop platforms (Windows, Mac OS X, Linux, Solaris), so access should not typically depend on an expensive upgrade (although we musn’t be glib about the costs in time and trouble for users to install and learn additional software, even when free). That list also represents an unusual level of support from assistive technology vendors for any new web technology. It seems practical reason enough for careful consideration, whatever the theoretical technical merits of WAI roles vs. traditional widget elements/attributes.
    Copy & paste the code below to embed this comment.
  6. From the concerns I see in the discussion ... > If you structure your page using the normal XHTML elements
    > and if you use meaningful alt-attributes and so on, people
    > with disabilities can already navigate your page.
    True, if you can make that choice that’s fine. What if your work for an organization that is on the leading edge of AJAX development, and isn’t interested in using semantic HTML. They want to use Javascript for widgets and even have live updates on the page based on real-world events? If you work at a place that is going to use web 2.0 and DHTML widgets, you’ll need some way to make that accessible. There is no other way to do that besides ARIA. Yes it’s hard but that’s why we’re putting it into Dojo. Other toolkits will hopefully follow. We may eventually get an easier solution like HTML 5. Then again that may take 7-9 years, if CSS 2 teaches us something. It would be great if HTML 5 has powerful widgets like tree views and spreadsheets with the accessibility built right in. But, in the mean time people will still be going nuts with Javascript. In reality, custom widgets will always be something developers will want the freedom to make.  Microsoft recognized this when the developed MSAA (Microsoft Active Accessibility) for Win32, which allowed developers to make owner-drawn custom controls accessible. You can’t have a widget set that pleases everyone, so it’s important to provide developers with a way to make their fancy custom widgets accessible. Otherwise accessibility is seen as holding back innovation. > This is not a progressive enhancement
    It does not change behavior or accessibility in places that don’t support it. Because ARIA is the only solution being proposed for all the wild stuff going on out on the Web now, I expect it has a place on the web. > using an unproven and non-compliant technique.
    We have proven that it works, please see the widget samples. The only thing non-compliant is the use of tabindex=”-1”. If that’s important to you, wait for the activedescendant support in Firefox 3, which is compliant, and is an alternative the use of tabindex=”-1”. As far as backwards compatibility with older screen readers, it works with older versions of Window-Eyes and JAWS as long as they work with Firefox at all. This is because we expose the new widgets so that they look exactly like the old widgets. Should everyone jump on ARIA right now? Probably not, but if a few start to use it that will help move things along. We’ll get there eventually anyway, but some killer apps with it will help pressure some of the big vendors to support it. That’s important, so that Web 2.0 stops being just a disaster for accessibility with no way to fix it.
    Copy & paste the code below to embed this comment.
  7. I may be completely off-base with my thinking here, but why can’t something like Microformats be used in a similar way to solve many of these problems?
    Copy & paste the code below to embed this comment.
  8. Well, microformats have traditionally been used for marking up or embedding data not creating custom widgets, but the draft standard for embedding WAI information into HTML 4.01 using the class attribute is very close to how microformats work: http://www.w3.org/WAI/PF/adaptable/HTML4/ Traditional microformats haven’t relied on UA and assistive technology implementations to get off the ground. It’s important for accessibility solutions to have backing from standards organizations so that conformance requirements are clear, so that anyone can implement them, and so that they can be made a W3C UAAG (User Agent Accessibility Guidelines) conformance requirement to be promoted to procurers. I have some doubts about whether the anything-goes model of the current microformats movement is particularly appropriate for that reason.
    Copy & paste the code below to embed this comment.
  9. First we need to get this standard out the door. The idea of having a Microformat version should be looked at once we’re done with that.
    Copy & paste the code below to embed this comment.
  10. The article unfortunately doesn’t really communicate exactly how this impacts development. In the current methods of adding screen reader support (see an example at http://juicystudio.com/article/making-ajax-work-with-screen-readers.php with excellent descriptions), it takes a lot of scripting in order to dynamically inform a screen reader that things have changed. These methods also rip the user out of whatever they’ve started reading or writing at that time, and drop their cursor wherever the change occurs. The later versions of Jaws don’t quite do that, but in order to support a broader user base, you need to do it that way…Jaws costs a lot of money for an individual to keep paying for every year. With WAI-ARIA, this gets handled just by adding an attribute of aaa:live, and you can fully control the urgency with which the screen reader will read the updated DOM elements! This not only keeps the user in their current context, but allows “polite” live elements to wait for the user to complete their current task before the user needs to hear it. Errors and other urgent information can either user “assertive” or “rude” in the worst case scenarios. This doesn’t even touch on some of the benefits of the other attributes available, but just the aaa:live attribute itself makes screen reader support infinitely easier to implement and much, much more flexible. You can see some good examples on the Firevox (open source, cross platform Firefox screen reader) site: http://firevox.clcworld.net/tutorial/tutorial.html Yes, this very new working draft has some time and work before it exist as a specification. But it needs support from developers in order to take off some of its rough edges, and for the more widely-used screen readers to start paying closer attention. WAI-ARIA can only help developers and we have every reason to help push this project forward.
    Copy & paste the code below to embed this comment.
  11. Trying to adhere to these standards puts Dojo ahead of the toolkit pack, in my opinion.
    Copy & paste the code below to embed this comment.
  12. It’s long, but I red iit in one read. Good stuff
    Copy & paste the code below to embed this comment.
  13. Finally the article has been “translated into German”:http://www.barrierekompass.de/weblog/index.php?itemid=541 and published at the Barrierekompass website. Thanks for all the positive feedback and comments, BTW. ;)
    Copy & paste the code below to embed this comment.
  14. It would be great to see more updates on ARIA from Alistapart, this looks like the most recent mention and nearly two years old! A nice semi-tech article could really make a difference, aria-required / aria-invalid for form elements? Strike me as really useful attributes for accessible JS.
    Copy & paste the code below to embed this comment.