aria-describedat

Status

On March 21, 2012 an unofficial aria-describedat document surfaced. It is a public working draft of a potential specification. aria-describedat has no official standing of any kind and does not represent the support or consensus of any standards organization.

It is unknown if or when specification aria-describedat would be complete. Possible introduction of aria-describedat in a future ARIA version, does not require the abolition of longdesc. Rather, it acknowledges that the idea behind longdesc is good.

Use Cases

No use cases for aria-describedat have been presented that are not already satisfied or could be satisfied by longdesc.

Bridging Technology

If aria-describedat ever does becomes an ARIA attribute it would remain a bridging technology.

Shirking off the responsibility of providing long description semantics to ARIA is retrograde. In other words, the premise is entirely backward. ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them. For full rationale please consult the bridging technology document.

Forces a Visual Encumbrance

By default aria-describedat as described in the unofficial/unsupported draft violates the forced visual encumbrance constraint.

Different Authors Have Different Skill Sets

Pitting aria-describedat and longdesc against each other is counter-productive to accessibility. It should not be an either/or situation. A different skill set exists between JavaScript library/app developers and the run of the mill content authors/web designers e.g. advanced skill set versus basic skill set. One group may learn ARIA to develop "Accessible Rich Internet Applications" the other will use basic HTML to put up a web page or a web site.

As Cliff Tyllick has said, it is unlikely that many content creators or web designers will learn ARIA (something not native HTML). They already feel like they've learned far more than they should have to know under their job description. And in many cases, their supervisors agree. Cliff goes on to say,

And the use case for needing this to be inherent to HTML5 is simply this: Many people who put content on the Web have training in nothing more than html. If you call any technique by a different name - whether it's Java, AJAX, or ARIA - they will not learn it. So if the means for attaching this information to an image is not within html, they won't use it.

Content creators/basic authors should not be forced to read another large spec besides HTML5 to make content accessible. These authors may know basic HTML and be willing to put in longdesc for complex images but most are not going to delve into other specs. ARIA is not an option for them. If content is to be made accessible by both groups of authors we need both mechanisms.

It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,

read the ARIA best practices guide carefully before adding ARIA markup to their pages.

Most basic content authors are not going to learn two languages to make images accessible. When accessibility is not relegated to a separate spec but integrated into the host language, it is viewed as a mainstay rather than as an afterthought or add-on. Educators have a hard enough time teaching HTML, and an even harder time teaching the need for accessibility (and the means to address those needs). Pile on yet another layer and the difficulties will increase exponentially.

ARIA is powerful technology. If HTML5 forces ARIA upon basic content authors in order to make content accessible, what these authors will end up doing with it is unknown. Encouraging people who don't intend to learn ARIA thoroughly to dabble in it could have unintended consequences. For instance, make a counter a live region - disaster - but it seems logical. Mark a section of your page as an "application" because to you it is an application - seems great. But if you don't handle every keyboard command - it's another disaster as role="application" removes the screen reader's navigation methods.

Two types of authors are recognized, differentiated, and provided for separately by other standard organizations. For example, in 508-255 Refresh (ANPRM) the Access Board provides Chapter 5 for document authors and Chapter 4 for app developers. They state,

Advisory 501.1 Scope. The provisions of this chapter apply to electronic documents, which are mostly static, read-only, non-interactive electronic content. Examples include Word files, PDFs, PowerPoint presentations, Excel spreadsheets, and simple web pages (which do not contain Flash). However, electronic documents may also contain interactive content, such as hypertext links, buttons, and form elements or fields. All of these elements are covered in this chapter. Electronic content covered by this chapter includes most non-paper documents and web content, regardless of format.

This chapter is oriented towards document authors, rather than developers.

Provisions relevant to more robust user interaction, including scripting, are found in Chapter 4 (Platforms, Applications, and Interactive Content). Additional requirements for audio and video content are found in Chapter 6 (Synchronized Media Content and Players).

Both advanced developers and the run of the mill content authors/web designers deserve to have suitable tools at their disposal for providing long descriptions. Both need to be provided for. Anything else is a false choice and binary thinking. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.

Lack of ARIA Educational Material

A longdesc support base exists in the form of authoring documentation, tutorials, books etc.

No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.

This situation has not changed. On June 1, 2012 Paul Irish repeated that statement,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is not at all appropriate for a web developer audience.

In contrast a longdesc support base already exists in the form of authoring tools, tutorials, books etc. These longdesc support materials will live on.

Lacks Backwards Compatibility

The aria-describedat would be void of all backwards compatibility. It is not:

For further rationale please consult the backwards compatibility document.

No Examples in the Wild

No examples in the wild of accessible long text alternatives with aria-describedat have been presented.

No Implementations

aria-describedat has no implementations.

Browsers

No evidence exists that browsers will implement aria-describedat or if they ever do in a way that conforms to use case constriants.

Authoring Tools

No evidence exists that authoring tools will implement aria-describedat. Indeed, authoring tool vendor Vlad Alexander has provided first-hand testimony stating,

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.

Reinvents the Wheel

Attempting to use aria-describedat for long descriptions would reinvent the wheel by duplicating a basic method that has already previously been created.

No Evidence of Improvement

No evidence has been presented that aria-describedat would produce more accessible content for long descriptions than longdesc.