Rebuilding The Web

Articles, advocacy, discussion and debate about the many problems of the Web and the challenges of rebuilding it.

Is ARIA for content doomed to failure?

ARIA adds hidden information to HTML to make widgets accessible. Some believe that ARIA can also replace existing HTML accessibility features to make content accessible. Is it worth the effort to remove specialized built-in HTML accessibility features in favor of this generic add-on technology, or is ARIA for content doomed to failure?

How does ARIA for content work?

ARIA for content is an attribute called aria-describedby that can be applied to any element. The aria-describedby attribute contains one or more IDs of elements that contain a description for the element in question.

The aria-describedby attribute must reference an element in the same document. For example:

  1. <table aria-describedby="desc1">
  2. ...
  3. </table>
  4. <p id="desc1">This table charts the number of cups of coffee consumed by each person, the type of coffee preferred (decaf or regular), and if the coffee is taken with sugar.</p>

When it is necessary to reference an external document, the aria-describedby attribute needs to point to a hyperlink, which in turn references the external document. For example:

  1. <p><img src="histogram.png" alt="Histogram of Blackberry tree heights." aria-describedby="desc2" /></p>
  2. <p><a id="desc2" href="blackberry-description.html">Data for Blackberry Histogram.</a></p>

Why is ARIA for content favored by some as a replacement for native accessibility features?

This question is actually hard to answer, because a decisive case has not been presented for using aria-describedby instead of longdesc for images or summary for data tables. No one is claiming that aria-describedby can produce more accessible content than longdesc and summary. Instead, the argument for replacing longdesc and summary with aria-describedby seems to be based on a belief that the new feature will get more support from stakeholders than existing features do.

The main critique of the native longdesc and summary attributes is that they contain content that is by default hidden from view for most users. Hidden content is considered bad by some people because hidden content is out of sight and therefore out of mind.

Unfortunately though, ARIA for content would only replace hidden content with hidden relationships. Would content authors find hidden relationships easier to work with than hidden content? Let's contrast the two approaches with illustrations. The following mock screen shot shows a table properties dialog box that displays when the author selects an insert table button in a WYSIWYG editor using the native summary attribute:

The Summary field contains a description.

The author enters the description of the table in the Summary field and it's done.

Now let's compare the same table properties dialog box with the Summary field replaced by a Description field that populates the aria-describedby attribute:

The Description field is blank.

What is the non-technical content author supposed to enter into the Description field? Even assuming users know how to create ID relationships, they cannot enter the ID of the element that contains the description for this table into the Description field, because the description has not yet been written elsewhere in the document.

Let's assume that after filling in the table data and writing a description of the table back in WYSIWYG mode, the user still remembers that the table needs to be associated with a description. This would require the user to edit the paragraph properties in order to assign a unique ID to the paragraph.

In WYSIWYG mode, the option Properties is selected from the context menu.

The following screen shot shows the paragraph properties dialog box with the Advanced tab selected. At this point, the user would need to enter a unique ID into the ID field.

The ID field contains an ID.

Back in WYSIWYG mode, the user then needs to select the option to edit the table properties as shown in the following screen shot:

In WYSIWYG mode, the option 'Table properties' is selected from the context menu.

Then, in the table properties dialog box the user would need to enter the ID of the paragraph that contains the description:

The Description field contains an ID.

In addition to the previous 5 steps, the content author must also be skilled in the naming rules for IDs, and must be aware of potential logical errors, such as circular references (when an element references itself or a parent element). The WAI-ARIA 1.0 User Agent Implementation Guide state that authoring tools are not responsible for logical validation, so the burden of validation will fall on the shoulders of non-technical content authors.

The hidden relationships created by using ARIA for content are not just significantly more complex to create for content authors; they also suffer the same shortcomings as hidden content. For example, description content can be deleted leaving aria-describedby referencing a non-existent ID. Or description content can get overwritten with unrelated content leaving aria-describedby pointing to content that is not a description of the given element.

Besides being significantly easier to author and understand, hidden content in longdesc and summary attributes has one big advantage over hidden relationships generated by ARIA: hidden content can be turned into discoverable content by applying innovative user-interface techniques. Discoverable content is information that is initially not visible but easily comes into view through user interaction. For example, the XStandard WYSIWYG editor has a feature called Images As Text that can display hidden content such as alternate text (content of the alt attribute) directly inside the document, and can apply editing and spell checking to hidden content just as it does regular document content.

Before and after screen shots. The before screen shot shows a image in the middle of a sentence. The after screen shot shows text in place of the image with markers around the text.

Conclusion

For any technology to take root and thrive on the Web, the affected stakeholders in the technology need to understand its benefits and support it. Authoring tool vendors are influential stakeholders in the process who can determine if ARIA for content lives or dies. As an authoring tool vendor, we will not be supporting ARIA for content in XStandard, and I cannot see that many other tool vendors will support it either. Implementing ARIA for content does not make business sense for authoring tool vendors, because the non-technical content authors who buy our tools will find it far too complex to use, and because using ARIA for content does not produce better results than existing accessibility features.

Public comments

1. Posted by Laura
on Wednesday 2011-07-06 at 05:10:00 PST

Hi Vlad,

Thank you very much for this timely article.

Joshue O Connor is working on a change proposal to reinstate table summary into HTML5.
http://lists.w3.org/Archives/Public/public-html-a11y/2011Jul/0024.html

This post could help provide new evidence for the case.
http://lists.w3.org/Archives/Public/public-html-a11y/2011Jul/0030.html

2. Posted by Sailesh Panchang
on Wednesday 2011-07-06 at 08:26:15 PST

Great arguments and very well reasoned. I hope this will ensure victory for supporters of table-summary and longdesc.
ARIA is not meant to replace native HTML-accessibility. Even the Intro to Aria document emphasizes that. Use it for purpose intended … to enhance accessibility of dynamic content and custom elements that have posed accessibility challenges.
There is no point in replacing simple techniques that are browser / AT supported by more complex techniques.
Secondly, browser / AT makers do not implement documented HTML accessibility features uniformly. So what is the chance that they will implement ARIA as documented right away as intended?
Some argue that native HTML accessibility features are not used correctly. That is hardly the fault of the accessibility features. So developers need to be trained. What is the chance that developers willsuddenly take to ARIA enthusiastically which is technically also more challenging?
ARIA attributes need to be manipulated via scripting and authors need to understand how user agents and AT behave and really be well educated about accessibility.
Sailesh

3. Posted by Marco Zehe
on Wednesday 2011-07-06 at 09:05:37 PST

Thanks for this well-written and illustrative article! I've always argued that ARIA is meant to augment, not replace, native HTML accessibility features. It is good to see that there are features in HTML5 that can actually replace some ARIA techniques such as aria-required and aria-invalid in modern browsers. I hope that those responsible will read this article carefully, and that Josh has success in reintroducing summary into the HTML5 spec!

4. Posted by Web Axe
on Wednesday 2011-07-06 at 10:50:46 PST

Great article, totally agree! Yes, ARIA is *supposed to be* a "bridging technology", but some folks at W3C just don't understand the big picture. The W3C needs to get it right, so the developers can do it right, so that browsers and AT can implement it right. It's too bad, shouldn't be this much of a fight.

5. Posted by mattur
on Wednesday 2011-07-06 at 13:15:59 PST

> "No one is claiming that aria-describedby can produce more accessible content than longdesc and summary."

aria-describedby points to element(s) on the page. Users with UAs that don't support it, or users who don't know how to use ARIA features in their UA, *can still access the content*.

All aria-describedby does in this case is progressively enhance the existing content with an explicit association *where required*.

The HTML WG decision on table summary is here:
http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html

> "Yes, ARIA is *supposed to be* a "bridging technology""

I'm not sure that's entirely true. Richard Schwerdtfeger, chair of the W3C's WAI-ARIA team:

"ARIA not a bridging technology [..] ARIA meant to be cross-cutting tech to support AT -- way to apply a11y semantics for SVG and CANVAS and HTML [..] there are advantages to having declarative API consistent across elements that can be controlled by AT -- not a bridging tech, but an a11y API feature that is declarative"

http://www.w3.org/2011/04/14-html-a11y-minutes.html

"bridging technology argument was to appease the HTML WG"

http://www.w3.org/2011/04/18-text-minutes.html

6. Posted by rob
on Wednesday 2011-07-06 at 14:10:13 PST

> "bridging technology argument was to appease the HTML WG"

Some say appeasement, others say consensus.

> I'm not sure that's entirely true. Richard Schwerdtfeger, chair of
> the W3C's WAI-ARIA team:
>
> "ARIA not a bridging technology [..] ARIA meant to be cross-cutting
> tech to support AT -- way to apply a11y semantics for SVG and CANVAS
> and HTML

Obviously not everyone agrees with this since an *appeasement* had to be made.

> users who don't know how to use ARIA features in their UA

That would include almost all the people who create content for the web.

mattur, what you don't seem to realizes is that the trade-off of using a "cross-cutting tech" is that it is so abstracted and complex that nobody knows how to use it.

7. Posted by Laura
on Thursday 2011-07-07 at 04:59:52 PST

"WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page. This is important because the invention of new types of objects is faster than standardized support for them appears in page languages.

It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it's better to use an h1 element in HTML than to use the heading role on a div element.

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature."

Source: Accessible Rich Internet Applications (WAI-ARIA) 1.0
http://www.w3.org/TR/2011/CR-wai-aria-20110118/introduction#co-evolution

8. Posted by mattur
on Thursday 2011-07-07 at 06:12:32 PST

You appear to have accidentally-on-purpose left off the final sentence of that quote, Laura. And the two following paragraphs :)

9. Posted by Misha Karnovich
on Thursday 2011-07-07 at 07:16:14 PST

@mattur, you are quick to quote others but those quotes are not directly related to this post. They talk about ARIA in general, not specifically using ARIA to remove and replace longdesc and summary.

Instead, why don't you @mattur contact the person you quoted, Richard Schwerdtfeger, and ask him if he thinks content writers will follow the steps described in this blog in order to use ARIA to make tables and images accessible.

10. Posted by mattur
on Thursday 2011-07-07 at 13:31:14 PST

Why?! I don't think it's entirely true to say ARIA is a bridging technology, and provided quotes to support that statement. It's also supported by the part of the WAI-ARIA intro text that Laura omitted.

Authoring tools already have to support <label for="">, #links, headers="", mapping element classes/id's to CSS, JS etc, so this is just extending an existing pattern.

There are of course also other UI approaches, less convoluted than the one Vlad outlined above. For example the table context menu could bring up "insert description before/after" options similar to how XStandard currently supports <dl> markup:

http://www.xstandard.com/en/documentation/xstandard-screen-shots/07/

I do think there's a possibility that, like summary and longdesc, ARIA could be doomed to failure. So universal design is essential, progressively enhanced with ARIA *where required*, to ensure web content is accessible to all.

11. Posted by Ted Drake
on Friday 2011-07-08 at 10:57:38 PST

I like your article, but I think the title is misleading. You are pointing out the inherent problems of replacing longdesc and summary with aria-describedby. That doesn't mean aria-describedby couldn't be used for other purposes.

I agree completely that longdesc and summary are the appropriate attributes. However, I'm hesitant to point the blame at ARIA, rather at those who are trying to abuse it as justification for getting rid of the existing attributes.

12. Posted by Angela
on Saturday 2011-07-09 at 09:37:48 PST

Vlad: Nice article. I especially like the way you implemented the concept of discoverable content for alt text.

Ted Drake: I agree the title could be clearer.

mattur: My company evaluated a lot of WYSIWYG editor and they all suck at doing hidden relationships that you hold as an example such as <label for="">, headers="", mapping elements classes/id's to CSS, etc.

Misha Karnovich: I for one would also like to hear from Richard Schwerdtfeger on his thoughts on how non-technical people are supposed to use aria-describedby instead of summary.

Sailesh Panchang: Totally agree with: "Some argue that native HTML accessibility features are not used correctly. That is hardly the fault of the accessibility features."

13. Posted by Sailesh Panchang
on Sunday 2011-07-10 at 17:00:10 PST

For Mattur (and Richard):
Well just because user agents may need to continue supporting ARIA does not mean that it is not a bridging technology. WAI-ARIA may be used as a short term fix to expose semantics and accessibility info till a markup language provides the mechanism natively. One cannot use ARIA in a vacuum to create Web content like HTML can. It is meant to be used with a markup language like HTML. That makes it a bridging technology.
Rightho,
Sailesh Panchang

Comments are closed for this article.

Main menu

Check out the a11y bugs project that aims to help browser / tool vendors fix accessibility bugs.