ARIA and Progressive Enhancement

by Derek Featherstone

12 Reader Comments

Back to the Article
  1. It does seem odd to use aria-required, role=“navigation”, and role=“complementary” when we have the required attribute, the nav element, and the aside element, respectively. But this is what typically happens when you have two drafts that are being worked on at the same time, you get a certain amount of duplication that must be addressed.

    In my mind, the reason for adding the new HTML5 tags was for the purpose of semantics, specifically for the ability of computer technologies to process the information provided in a more meaningful way. To this end, I would hope that assistive technologies would recognize these elements and attributes and make use of them without necessary duplication.

    As you said, what we need is a way to detect whether ARIA is supported by both the browser and any assistive technology the user may have. Without that, it becomes very difficult, if not impossible, to support both ARIA accessibility and normal accessibility techniques (such as tabbing between links).

    Copy & paste the code below to embed this comment.
  2. To this end, I would hope that assistive technologies would recognize these elements and attributes and make use of them without necessary duplication.

    Russell—you’re on the mark here. The problem is, that won’t happen for a while, and when it does, we’ll still have to support older user agents such as current screen readers that don’t support those elements that will eventually provide the semantic we want.

    Copy & paste the code below to embed this comment.
  3. The statement screenreaders don’t support required, isn’t really true. All screenreaders, wich do “support aria-required”, do also “support HTML5’s required” attribute. The only reason, why they didn’t announce the required attribute, is because the browser you have used, doesn’t support HTML5 required attribute and therefore doesn’t expose the accessibility informations through the a11y-api.

    If you would test the required attribute with FF4beta7 and Jaws 9/nvda, you would see, that it is supported. I think you should change this part of your article.

    There is a lot of confusion, what is done by a screenreader and what by the browser. For example, you often here, that “Jaws would announce the last label of multiple labels while nvda/voiceover would read the first label”:http://www.456bereastreet.com/archive/200809/multiple_form_labels_and_screen_readers/. But this isn’t true, either. The accessibility name (label is part of the a11y-name calculation) is exposed by the browser. If you would test with Jaws in FF, it will also read the first label.

    Copy & paste the code below to embed this comment.
  4. I was planning a lengthy response to to this article, but Jared said it well already.

    “WebAIM: The Ghosts of ARIA Present and Future”:http://webaim.org/blog/the-ghosts-of-aria-present-and-future/
    URL: http://webaim.org/blog/the-ghosts-of-aria-present-and-future/

    Some out-of-context, but choice quotes from the article:

    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.

    By suggesting that full ARIA support and fallbacks are required, we are encouraging that these apps remain inaccessible into perpetuity.

    the result of asking web developers to hold off on innovating until ARIA support improves is that developers will instead innovate anyways without ARIA support at all. The result is much worse accessibility.

    If we focus on supporting ARIA as it is now, support will largely remain how it is now. We should instead advocate that developers build things following standards, increase our pressure on browser and assistive technology vendors to increase their support, and help users understand the increased accessibility they can experience by using standards-compliant web browsers and assistive technology. The future of ARIA is bright, but only if we make it so.

    Copy & paste the code below to embed this comment.
  5. James—great quotes, and a great piece by Jared. Here are a few responses:

    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.

    I don’t think this is quite accurate—there are two options only for those things that simply cannot be made accessible without ARIA. But what about things that can be made accessible without ARIA? We have two different options then:

    1. build it to be accessible without ARIA for when ARIA isn’t supported
    2. build it with additional ARIA support so that it really sings when ARIA is supported

    By suggesting that full ARIA support and fallbacks are required, we are encouraging that these apps remain inaccessible into perpetuity.

    Again, only for those certain things that absolutely require ARIA to be accessible at all. And even then having fallbacks that provide some, but imperfect, accessibility is better than not. What I really want is that people think carefully about non-ARIA scenarios.

    the result of asking web developers to hold off on innovating until ARIA support improves is that developers will instead innovate anyways without ARIA support at all. The result is much worse accessibility.

    Definitely not my intention to suggest holding off on innovation—I’m all for it. Just careful consideration of using ARIA and the scenarios where it isn’t supported and providing something… anything that makes it more accessible, even without. And an important part of this is, I think, being careful to avoid conflicts in JavaScript behaviours and not making the assumption that we have ARIA support—at least for now.

    If we focus on supporting ARIA as it is now, support will largely remain how it is now. We should instead advocate that developers build things following standards, increase our pressure on browser and assistive technology vendors to increase their support, and help users understand the increased accessibility they can experience by using standards-compliant web browsers and assistive technology. The future of ARIA is bright, but only if we make it so.

    Absolutely. We must push. Make it better. I’m not saying that you or Jared are suggesting this, but I’m not prepared to throw away non-ARIA solutions any time soon. Are you? Should others be?

    Copy & paste the code below to embed this comment.
  6. RussellUresti, much of the semantic duplication (semantic overlap, realyy) you’ve noticed is due to HTML5 adopting ARIA features. For example, aria-required predates @required, and was adopted in HTML5 after members of the HTML Working Group reviewed an earlier draft of ARIA. Two related notes:

    1. ARIA encourages adoption of ARIA features into host languages. No problem there. There are even precedence rules for if the host language attribute and the ARIA attribute values conflict, e.g. <input required aria-required=“false”> (@required wins in this case)

    2. Host languages typically limit native attributes to certain elements. In this case, required is limited to valid use on native form elements. aria-required is still valid on any element, including generic elements with repurposed roles. For example, a rich text edit field could be achieved by doing this: <div role=“textbox” aria-required=“true” c>value here</div>”¦ HTML5 @required would not be valid in that case so, although there is semantic overlap, there is rarely exact duplication.

    Copy & paste the code below to embed this comment.
  7. I’m not saying that you or Jared are suggesting this, but I’m not prepared to throw away non-ARIA solutions any time soon. Are you? Should others be?

    Of course not, but 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 web pages with some widget functionality, progressive enhancement with cautious ARIA addition is still the best approach. For full-blown web applications like GoogleDocs or MobileMe, progressive enhancement, though sometimes possible, is hardly a practical, performant solution.

    ARIA allows the original application to be made accessible, and even WCAG2 no longer recommends the separate-but-not-really-equal approach of requiring web apps work without JavaScript. WAI-ARIA is essentially in the process of defining the accessibility API for the Web.

    Copy & paste the code below to embed this comment.
  8. I hope it’s clear that my article (http://weba.im/ariaghosts) is not a critique of what you’ve written. I absolutely agree with your article. My hope is to expand and give a more positive spin on a few things.

    While you are not suggesting that we hold off on innovation, I think that presenting the complexities and rather sad state of current ARIA support, especially on such a popular and influential site, may scare folks away from ARIA altogether. It’s difficult, though important, to present the gory, depressing details of present day without dissuading future innovation and implementation.

    Copy & paste the code below to embed this comment.
  9. James,

    This is the part that I’m interested in:

    ARIA allows the original application to be made accessible, and even WCAG2 no longer recommends the separate-but-not-really-equal approach of requiring web apps work without JavaScript

    Agreed—I’ve always been a big believer that the JavaScript on/off scenario is interoperability more than accessibility. I also believe that if you can provide something without JavaScript easily, then yes, we should be doing that too.

    What I’m really interested in is things like the tabs scenario that I outlined where the assumption that ARIA support exists actually makes the interface stop functioning properly unless you actually DO have ARIA support.

    Copy & paste the code below to embed this comment.
  10. input[aria-required=true]::after { content(”(required)”) } will not work.

    The ::after pseudo-element would be nested inside the input element (as if it was <input><input-after>(required)</input-after></input> in the markup), but the input element is declared as empty by HTML 4/XHTML 1 DTDs and HTML5 spec, thus must not have content.

    It doesn’t work in IE, Firefox and Webkits. Opera displays the generated content but behaves strange (no border for the input control).

    Copy & paste the code below to embed this comment.
  11. One important point—special thanks to “Jason Kiss”:http://accessibleculture.org for his work with “ARIA Tabbed panels”:http://www.accessibleculture.org/research/aria-tabs/. His research and testing was referenced and used heavily in the tabbed panels section of this article. We based our code on his, because… well, because it was so very thorough and well-thought out.

    Thanks, Jason!

    Copy & paste the code below to embed this comment.
  12. I’m curious if there is a specific reason for using JavaScript to insert some of the ARIA attibutes (role=“tabpanel”, role=“tab”,  role=“presentation”, etc.) instead of hard-coding it into the HTML? I understand the reasoning for (aria-selected, aria-hidden and tabindex).

    I would also suggest preventing the default scrolling action of the arrow keys on the tabList keydown events.

    Copy & paste the code below to embed this comment.