Comments on The Accessibility of WAI-ARIA

11 Reader Comments

Back to the Article
  1. “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.

    Copy & paste the code below to embed this comment.
  2. Other than this I thought it was a very good article. :-)

    Copy & paste the code below to embed this comment.
  3. 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. “”:

    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.

    Copy & paste the code below to embed this comment.
  4. 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*.

    “The Ghosts of ARIA Present and Future”: on WebAIM.

    Copy & paste the code below to embed this comment.
  5. 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*.

    Copy & paste the code below to embed this comment.
  6. 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.

    Copy & paste the code below to embed this comment.
  7. 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.

    Copy & paste the code below to embed this comment.
  8. 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.

    Copy & paste the code below to embed this comment.
  9. Sorry, commenting is closed on this article.