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
It is unknown if or when specification
aria-describedat would be complete. Possible
aria-describedat in a future ARIA
version, does not require the abolition of longdesc. Rather, it
acknowledges that the idea behind longdesc is good.
No use cases for
aria-describedat have been
presented that are not already satisfied or could be satisfied by
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.
aria-describedat as described in the
unofficial/unsupported draft violates the forced visual encumbrance
against each other is counter-productive to accessibility. It
should not be an either/or situation. A different skill set exists
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
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
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.
longdesc support base exists in the form of
authoring documentation, tutorials,
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,
longdesc support materials will live
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 of accessible long text alternatives
aria-describedat have been presented.
aria-describedat has no implementations.
No evidence exists that browsers will implement
aria-describedat or if they ever do in a way that conforms to use case constriants.
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.
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 has been presented that
would produce more accessible content for long descriptions