11 Reader Comments

“But as long as older screen reader/browser combinations incapable of interpreting WAI-ARIA still constitute a significant part of the installed base, web designers who care for accessibility should use WAI-ARIA markup only to enrich their sites. They should not rely on it”

This is an absolutely ridiculous statement. If you follow this logic nobody should write to HTML 5. There is not a single AT out there that supports the full features of HTML 5. It also makes a statement that companies should not try to invest in accessibility. For example, this statement argues that a major company like IBM should not invest in fixing things like JavaScript accessibility as the ATVs and users are not upgrading their work or tools.

The bottom line is new government requirements will demand ARIA support to meet WCAG 2 compliance for most web applications. Otherwise, they will be simply inaccessible.

So, as the industry converges on rich web applications ATs will need to add HTML 5 and ARIA support and users will need to upgrade. At IBM we have hundreds of products now integrating ARIA support and we are looking to HTML 5 - especially for mobile. This will require advanced browsers and advanced ATs and we are seeing our customers make the investment in these new solutions.

This article’s argument implies that authors should write to HTML 4.01 and static content because ATs and AT users will not upgrade to support HTML 5 (which includes ARIA) or HTML 4 plus ARIA.

Although I think most of your points are fair, I do tend to agree with Rich that both articles tend to lean towards the fear/unrest/doubt side of the spectrum. Is it really a surprise that implementations have bugs when the spec isn’t even finalized? Please continue to encourage authors to both 1) use ARIA, and 2) report any bugs to the browser and assistive technology vendors. The more web developers report bugs, the faster those bugs get fixed.

Also keep in mind that ARIA is primarily meant to solve accessibility problems for web apps (the ‘RIA’ in ARIA) that previously had no way to be made accessible. For example, a spread sheet app or an Ajax-powered web mail application. Although backwards compatibility is a concern, most of the problems it’s solving don’t have any accessible solution, so that issue is not as prevalent in the RIA space. WAI-ARIA is essentially in the process of defining *the* accessibility API for the Web.

As for the robustness issue you mentioned, have you seen our ARIA proposal for User Interface Independence? I’d be interested to hear your thoughts on it. “http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html”:http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html

One final comment on your ‘two arches’ idea. Don’t forget that the third arch is an ARIA-aware assistive technology. Accessibility requires a web application, user agent (browser), and assistive technology (e.g. screen reader) to all work in harmony. While most web developers are not used to the broad range of combinations that entails, it’s not an insurmountable task. It’s a big task, but we’ll get there. Remember that, when this site (ALA) launched, all web developers were using tables for layout due to inconsistencies in the CSS support. Someday these ARIA inconsistencies will also be a relic of the past. Cheers.

Jared Smith eloquently cut to the core of the point I was trying to make.

bq. Developers will continue to innovate with or without accessibility. Because not building it is not an option and because some things cannot be made accessible without ARIA, *developers are left with two options — build it potentially accessible with ARIA or build it perpetually inaccessible without ARIA*.

@ schwer@us.ibm.com: My conclusion should not be read to imply that developers should not use HTML5 or ARIA. The site “sos-kinderdorf.de”:http://www.sos-kinderdorf.de from which I took the (non-ARIA) slider example is actually an interesting case since it uses HTML5 *and* WAI-ARIA *and* goes a long way to ensure that content is also accessible with older assistive technology lacking WAI-ARIA support (it also works — sort of -with JavaScript turned off).
Our point is rather that *if* developers use ARIA, they should be well aware of the limitations that currently exist. From a user perspective I would add that they should aim for simplicity and clarity and the use of native elements wherever possible. (And if they use the front page as a stage for layers upon layers of content — as on the sos-kinderdorf site - then they’ll have a hell of a job to make all that accessible!)
I guess that most people frequenting this site agree that making things as simple and as elegant as possible is a worthy goal. The trend towards mobile user agents will help - take Luke Wroblewsky’s take on “designing for mobile first”:http://www.lukew.com/ff/entry.asp?1117). We think this is the right approach because it rids sites of unnecessary complexity.
Currently, however, we can witness the opposite trend in web design: developers rush to implement all manner of fancy widgets and custom controls. Mostly proceed without making their stuff accessible — often not even on the level of properly managing focus order, let alone by adding WAI-ARIA. So there we see a risk that developers will just slap on some WAI-ARIA without proper testing and then claim they have created accessible applications.
I think what does come out clearly from both articles in this ALA double issue is that currently, diligent testing with AT is needed to ensure that WAI-ARIA enabled widgets actually work across a range of commonly used technologies out there.

??ARIA is primarily meant to solve accessibility problems for web apps (the “˜RIA’ in ARIA) that previously had no way to be made accessible??

Using WAI-ARIA diligently and reporting bugs to improve it is the right way to go for web application developers. (And, for the time being, providing a working alternative for users without ARIA-support, at least for crucial services and information that must be available for everyone.)

Thanks for pointing to the “User Interface Independence for ARIA” W3C proposal. I understand your reservations about the DHTML Style Guide WG keyboard shortcuts. I think the mechanisms you propose are quite elegant: they place the burden on the web app to pick up common user input in a user interface- and platform-independent manner, and to act on these events sensibly. If implemented widely that would remove some of the headaches regarding the predictability of interaction (consequences) that users encounter in web apps.

In my arches metaphor, I took the second arch to to stand for the ensemble of UA and AT, but I agree that three arches would have been better.

Thank you for a thorough summary. Accessibility seems to have been slipping off the agenda in the wake of ajaxy excitement. As a UX designer, I love the improvements HTML5 etc. bring to the user experience. But surely tech advances should be made from an inclusive standpoint first. (Think how much harder life is for some disabled users now everything is touch-screen oriented for example. Even as a left-hander with the slight shakes life is getting a little frustrating!)

To be honest, I’ve found it hard to get to grips with the issues and this article has summed the up nicely, putting me and others in a better position to address the challenges and innovate *safely*.

Detlev, thanks for posting a great article. Your article sets an interesting tone about semantics and equivalence. From your post, it seems that to some extent ARIA will be easy to implement, practical and effective to attaining equivalence. However, when we extend it to rich internet applications where incremental changes occur relative to a control, we may take functionality away from screen reader users especially when live regions come into play. I wish we could predict how users would cruise around using ARIA, 10 years from now. It will be interesting to see how users will create additional mental maps to capture dynamic changes on the page using ARIA.
Regarding the sampled users in your article, can we assume that screen reader users in general do not really care about ARIA? Moreover, even if they would want to embrace it, would there be a learning curve? Especially, when we consider how sighted non-disabled power users will want to leverage the advancements made in this space to their advantage. However, the variables (browser vs. AT versions, browser vs. AT vendors etc.) are enough to make us rethink and ask ourselves a key question. Why are organizations not including accessibility reviews of their designs? I know some have made it mandatory to get a compliance certificate before an application goes live but it is not enough. It should be made mandatory to have a design that is inclusive of most, if not all, user groups.

@ Devarshi: You ask whether blind users care about ARIA. If you start asking around in the community, you are more likely to get answers from users that are informed. Some actively promote ARIA, others emphasize that ARIA support is not yet widespread enough to rely on it.
In any case, informed users realize that without ARIA, many of the dynamic bells and whistles that modern web sites carry (like it or not) will remain inaccessible.
Blind users not interested in technical stuff are often not aware of ARIA (compare “WebAim’s Screen Reader User Survey Results”:http://webaim.org/projects/screenreadersurvey2/#landmarks where about 40% said they did not know that ARIA landmarks existed) . But then, they wouldn’t need to be - provided they have UA and assistive technologies that support WAI-ARIA, they will benefit when widgets are properly exposed.
Whatever view you take on ARIA: the ability to use it to make widgets accessible to (many) screen reader users should not be taken as an invitation to make an interface more complex than it needs to be.

The problem with the recommendations and discussion is that it relies too much on the developers and testers, and not enough on policy makers (gov and company). Detlev, your statement: “I think what does come out clearly from both articles in this ALA double issue is that currently, diligent testing with AT is needed to ensure that WAI-ARIA enabled widgets actually work across a range of commonly used technologies out there.” is too “currently” focused and seems to but all the burden on the developers. Where is the recommendation that policy makers promote, fund, and facilitate upgrades to AT, browsers, and other user agents that support all this accessibility investment? I agree developers need to be wise in adopting new UI paradigms and keep things simple, but many of us have enjoyed the rich accessible UI widgets from Windows and other desktop platforms that need to be made available in the web browser, and as mentioned - perhaps more importantly the rapidly emerging mobile smart phone platforms/apps. We all have to have a balanced view to the future, with policy makers (gov and company) and users picking up their part of the responsibility too along with the developers and testers. As the W3C WAI correctly focuses, there are ALSO standards for “User Agents” and “Authoring Tools” too - its not all “Web Content” that has the responsibility. All the stakeholders (technical standards, content developers, platform developers, testers/tools, user agent developers, AT developers, end users AND policy makers) ALL have a part in this journey - if we work EFFICIENTLY together, we’ll get there faster, with better accessibility.

Often what I call “dumb policies” that prevent users at companies and government agencies from upgrading to newer browsers and AT - are just that - dumb policies. Screen readers users and other AT users already have unique configurations, and should be allowed, in fact encouraged and supported to upgrade to later browsers and AT so that the burden to test and support older inefficient and inaccessible technology is removed or at least reduced. Governments and public policy has a role too in areas where AT or support is not available yet in a native language - they should more wisely support the lower investment in AT than to require the higher costs in providing duplicate or dumbed down interfaces. We had this debate when moving from command line interfaces to graphical user interfaces (e.g. DOS to Windows), we had it when moving from static HTML to e-commerce, and we’re having it yet again moving to RIA and HTML 5. Persons with disabilities deserve access to the front door like everyone else. Lets educate the policy makers that there are smarter investments and trade offs.