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:
<table aria-describedby="desc1">...</table><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:
<p><img src="histogram.png" alt="Histogram of Blackberry tree heights." aria-describedby="desc2" /></p><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 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:
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.
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.
Back in WYSIWYG mode, the user then needs to select the option to edit the table properties as shown in the following screen shot:
Then, in the table properties dialog box the user would need to enter the ID of the paragraph that contains the description:
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.
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.
Comments are closed for this article.