1 Semantic duplication

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

posted at 02:08 pm on November 30, 2010 by RussellUresti

3 It's a borwser issue not a screenreader issue

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

posted at 08:23 pm on November 30, 2010 by alexander.farkas

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

posted at 12:10 am on December 1, 2010 by James Craig

6 Re: Semantic Duplication

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” contenteditable=“true”>value here</div>… HTML5 @required would not be valid in that case so, although there is semantic overlap, there is rarely exact duplication.

posted at 01:07 am on December 1, 2010 by James Craig

7 Re: Great Quotes

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.

posted at 01:22 am on December 1, 2010 by James Craig

8 RE: Great quotes

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.

posted at 01:44 am on December 1, 2010 by Jared Smith

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

posted at 08:57 pm on December 1, 2010 by Gunnar Bittersmann