Misleading
This proposal is misleading. It is titled "Keep the longdesc
attribute for the img
element deprecated". However, it does not
deprecate longdesc
. It obsoletes it entirely. The concept "deprecate"
does not exist in HTML5.
According to the HTML5 specification
obsolete features must not be used by authors. Obsolete features trigger
errors. An error for a proper longdesc
is simply wrong. People should
not be reprimanded for doing the right thing. On the contrary, they should be
applauded.
Incremental renovation and improvement is more productive than "bulldozing" a feature flat.
Fails Requirements
aria-describedby
fails to meet long description
requirements. Among those requirements are:
- Does not force a visual encumbrance or default visual indicator on sighted users.
- Programmatically ties a set of structured content external to the document to an <img> element.
- Provides easy reuse of the targeted description from multiple sources.
- Is not forced upon screen reader users whether they want it or not. They can interact with it at their own will.
- Does not require any change or "messing" with the ARIA role or of the <img> element.
- Does not force people to read another large specification.
- Provides ease of use.
- Provides ease of authoring.
- Provides native HTML long description semantics.
- Is recognized by existing authoring tools, user agents, assistive technologies.
- Does not reinvent the wheel.
- Provides solutions to specific use cases.
In particular the following problems make this proposal a non-starter.
No Evidence of Use Case Fulfillment
No evidence exists that aria-describedby
satisfies the use
cases.
Does Not Work for Authors
Not Being Displayed Visually is a Key Designer Requirement
The history of longdesc
goes back to a time when designers (not
engineers) expressed a need to provide the functionality that non-sighted users
required, without it impacting the visual design of their page/content. The reason
for the creation of longdesc
in the first place was that designers
wanted a means to ensure longer descriptions could be provided without having a
visual encumbrance on their page. The longdesc
attribute was developed
to address this designer need, based on designer feedback.
The Association of American Publishers (AAP) has attested that piecemeal, workarounds for not forcing a visual encumbrance creates complexity, inconsistency, and unreliability. In particular they point out that hiding long description link text visually,
would require custom CSS or scripting. The mechanism for hiding the link would therefore differ product-to-product, making browser extensions or features to show the links more complex to code and less reliable for users.
It is appreciated that this proposal acknowledges and attempts to address this requirement.
However, not only do serious problems with pointing inside
hidden elements exist but also no evidence has been presented that WYSIWYG
authoring tools support the proposed aria-describedby/hidden
technique. It has been well established that numerous WYSIWYG web designer authoring
tools support longdesc
, an attribute that by design does not force
a visual encumbrance upon sighted users.
Adds Needless Complexity
No evidence has been presented that authors will get
aria-describedby
correct more often than longdesc
. In
fact it is far more complicated for ordinary authors and designers to author hidden
relationships than provide a simple link via a longdesc
attribute.
The workaround presented in this proposal would be very cumbersome and error
prone. No one would want redundant text on-screen, as it would state what is
visually evident. So to use aria-describedby
, a person would have to
write the content, then hide it, and then reference the hidden text with
aria-describedby
using hidden relationships. That's so burdensome that
surely even the most enthusiastic ARIA supporter should realize that the
longdesc
attribute is far more efficient.
Vlad Alexander thoroughly explains in the article Is ARIA for content
doomed to failure? how the aria-describedby
technique is far too
complex. The capacity for author error is great. Likely errors include but are not
limited to:
- Getting
ID
naming rules wrong. - Logical errors, such as circular references.
- Accidentally deleting the description leaving
aria-describedby
referencing a non-existentID
. - Accidentally overwriting the description with unrelated content leaving aria-describedby pointing to content that is not a description of the given element.
The potential for confusion is rife especially for ordinary content authors and
designers and the result is that accessibility will suffer. In fact even ARIA
experts have gotten ID
naming wrong and publish incorrect
ID
examples in the W3C WAI-ARIA 1.0 Authoring Practices
specification.
No aria-describedby
/hidden
tools exist to help authors
in this task, whereas authors possess an array of tools to
author longdesc
and to check that
longdesc
works in browsers.
The aria-describedby
/hidden
technique is complex. In
contrast longdesc
is simple. As
Kyle Weems illuminated,
are we going to pretend that using
longdesc
is difficult? Yes, people may use it wrong without some correction, but simply saying "Hey, put a URL there," is not complex at all
The Association of American Publishers (AAP) concurs. In regard to their production processes and quality assurance the AAP has provided first-hand testimony to the working group stating,
The
longdesc
attribute is easy to code.
Description Available in a Separate Document is a Key Author Requirement
As documented by the use cases and evidenced by real world examples a
description available in a separate document provides easy reuse of the targeted
description from multiple sources (i.e. ability for an image to appear in multiple
documents throughout a site or throughout multiple sites or from an HTML email
while at the same time linking to one longdesc
document).
For instance the CSS Squirrel, the
Texas State
Library, and the University of Minnesota
Duluth use images in separate documents that share the same long
description page. This technique is key to the logo description use
case as evidenced on numerous sites.
Geoff Freed has indicated that professional content producers (such as those
involved in the ePub initiative, and the US federally-funded DIAGRAM Project) are
interested and ready to use longdesc
to externally store descriptions
to facilitate
etext descriptions and describe etext
Images.
aria-describedby
as implemented lacks this functionality. It is
limited to on-page descriptions.
Global control for all instances is a powerful technique. It makes maintenance easy wherever instances of the same image exist in numerous locations. This is akin to the power of external style sheets.
In addition if long descriptions were hamstrung to on-page only, it would add
page weight inhibiting performance and slow pages. Longdesc
allows for
leaner code overall - you only do your http transport on demand, resulting in
smaller, faster pages, and reduced bandwidth consumption.
Different Authors Have Different Skill Sets
Pitting aria-describedby
and longdesc
against each
other is counter-productive to accessibility. It should not be an either/or
situation. Longdesc is needed and aria-describedby
is needed. 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.
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.
For further rationale regarding author skill set please refer to my objection to the Zero Edit/Obsolete proposal.
Lack of ARIA Educational Material
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.
In contrast a longdesc
support base already exists in the form of
authoring tools, tutorials, books etc. These
longdesc
support materials will live on.
Does Not Work for Users
Problems with Pointing Inside Hidden Elements
The hidden
Hack is Nonsensical Double-Speak
The HTML specification currently states,
The hidden attribute must not be used to hide content that could legitimately be shown in another presentation.
This change proposal changes the hidden
attribute's spec text
to,
Elements that are not hidden should not link to or refer to elements that are hidden. However, ARIA attributes are exempted from this rule and are allowed to point to contents inside hidden elements.
Hence the editors draft was changed in January 2012 to state,
The
hidden
attribute must not be used to hide content that could legitimately be shown in another presentation... if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers...It would be fine, however, to use the ARIA
aria-describedby
attribute to refer to descriptions that are themselves hidden. While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.
The spec text explicitly says that hidden
must not be used to hide content. Then it turns around and asserts it is okay to use it with aria-describedby
to point to hidden content. This double-speak not only adds ambiguity and confusion for authors, the hack directly subverts the hidden attribute's
meaning without consideration of repercussions.
This technique sets an unacceptable double standard because the hidden content would not only be legitimately relevant to screen reader users, it could be vital.
Layering this hack on top of the inherent complexity of aria-describedby
would increase author error exponentially. In contrast longdesc
is simple and does not require a hidden
hack. If this text is left in the spec, some developers would be provided a complex technique. However, it introduces inconsistency and confusion. It is
ambiguous, error prone, and would be difficult to comprehend and put into practice especially for novice authors.
No Discoverability Requirements
This purposed spec text,
Elements that are not hidden should not link to or refer to elements that are hidden. However, ARIA attributes are exempted from this rule and are allowed to point to contents inside hidden elements.
does not provide any requirements on user agents to help
interested users like authors or people with low vision who may be aided by
access to the long description discover hidden elements. In contrast the Include
longdesc
in HTML5 Change Proposal specifies this needed
functionality.
hidden
is Hidden From Screen Readers
Most common screen readers in use today will ignore elements that have been
hidden using the display:none
; declaration. When material is
hidden from visual display on a screen in this manner, it is hidden it from screen
readers. As
Roger Johansson recently explained,
Setting an element's display CSS property to
none
makes it completely invisible. It doesn't generate a box, it doesn't take up any place, it doesn't affect the layout. display:none hides the element - and its descendants - visually, and it also hides the element from screen readers
In both Gecko-based (Firefox, Seamonkey, ...) and Webkit-based (Safari, ...)
browsers the hidden
attribute is implemented by applying CSS
display:none
. This means that the long description using the proposed
hidden
technique would be hidden from its target audience.
Consequently it is obviously wrong to point inside hidden elements.
Two-Step Retrieval Instead of One-Step Retrieval
The effort for users to retrieve a description is significantly and negatively impacted. The Association of American Publishers has provided the working group first-hand testimony on this matter stating,
Since the
aria-describedby
attribute points to a link or to other content on the same page, its structure implies a two-step process to reach the text alternative. Compared withlongdesc
, the two step process is more tedious:
- The user moves to the object that aria-describedby references
- If the object is or contains a link or a button, the user interacts with that object to move to the text alternative.
Even if the link worked (which it wouldn't), this means
that screen reader users would need to exert double the effort to retrieve an
aria-describedby
description than they do with longdesc
.
People with disabilities face some unique challenges and barriers. Doubling their
on-task work load is needless and intolerable.
Supporting Structured Text is a Key User Requirement
Even though it can point to structured content such as bulleted lists and
paragraphs aria-describedby
can only process structured content as
string-text. This is because the accessibility APIs that aria-describedby maps to
do not support structured content due to tab focus
requirements.
This means that assistive technology treats aria-describedby
target
content as though it does not have any mark-up. It is treated as a string. All
structure is stripped clean. A user's reading keys will not work. Users are not
able to interact with the content. All links are dead.
This is not a problem with longdesc
. Longdesc
supports
structured content. Reading keys and links work.
Not Being Forced Upon Users is a Key User Requirement
With aria-describedby
the description is forced upon screen reader
users whether they want it or not. They cannot interact with it at will.
aria-describedby
is read aloud without any user intervention, forcing
the screen reader user to listen to it each and every time they encounter the image
whether they want to or not. The user is not able to control how they interact with
the long description.
As the Association of American Publishers has explained,
aria-describedby
cannot be silent by default in screen readers when used on images, compromising its use to illustrate that the content of an image is already available on the page.
Such behavior makes aria-describedby
a non-starter.
None of this is a problem with longdesc
as it supplies descriptions
on-demand and not by force. Longdesc
is an "escapable
structure" as Janina Sajka illuminated.
Distracting and Frustrating Circular User Experience
AAP goes on to explain that,
Developers may not realize the distracting and frustratingly circular user experience that this would cause and might use
aria-describedby
to point to, for example, a paragraph just above the image. Users would then likely follow thearia-describedby
announcement, expecting to find additional content, but they would arrive, instead, at a paragraph that they have likely just read.
Lacks Vendor Support
Authoring Tools
No evidence exists that authoring tools will implement
aria-describedby
or hidden=""
.
Indeed, authoring tool vendor Vlad Alexander has provided first-hand testimony stating,
Authoring tool vendors are likely to find it difficult (or even impossible) to build user-friendly interfaces that use the
aria-describedby
feature. This is likely to result in confusion and little use of the feature.
He confirmed on July 5, 2011 that,
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.
However, Vlad
Alexander has envisioned a user friendly longdesc
authoring tool.
He stated,
As a WYSIWYG developer, I can imagine a user-friendly interface that can encourage not only the use but also correct use of
longdesc
. I cannot say the same foraria-describedby
for images.
As evidenced he has not only envisioned an improved
longdesc
interface, but he also implemented
one.
User Agents
No evidence exists that user agents will implement aria-describedby
or hidden=""
uniformly and in the manner intended by its designers.
For example as tested
and reported by Steve Faulkner the
latest versions of NVDA and JAWS used with IE 9 will not announce descriptions unless
tabindex=-1
is added to elements such as p, div and span when referenced fromaria-describedby
oraria-labelledby
that reference multiple elements
Browsers
No evidence has been presented that any browser makes hidden content referred to
by aria-describedby and
hidden=""
discoverable to all
users. This need is entirely missing from this
proposal.
In contrast, longdesc
has an
existing support base (two browsers that natively support it, three if we count
Home Page Reader which is currently still in use in Japan). It has a growing
arsenal of
extensions, configurations, and plugins that enable discoverability and
provides the required functionality.
ARIA is intended to only affect accessibility API mappings (and thus ATs). Features such as alt="", however, are relevant far beyond AT users, for example to text browsers. It would be wrong, therefore, to make solutions that exclusively affect accessibility APIs be a suitable alternative for solutions that are necessary for UAs that do not use accessibility APIs.
Furthermore by specifying UA behavior
for longdesc
as accomplished by the Include
longdesc
in HTML5 Change Proposal we uphold the Priority
of Constituencies and give all users the benefit of this useful attribute.
Is a Bridging Technology
The
original decision on Issue 30 specifically addressed Accessible Rich Internet
Applications (ARIA). It said that the "native feature would be preferred over ARIA
bridging" argument would apply to the decision if the feature had known use cases.
Ample longdesc
use
cases have now been supplied to the Working Group. So the ARIA bridging
argument now applies.
ARIA is not meant to replace native HTML accessibility. The Protocols and Formats (PF) Working Group's Charter states,
Note that WAI-ARIA is intended to be a bridging technology. 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 was reinforced by Al Gilman, prior PF Chair, on behalf of that Working Group,
The working group likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements, such as widgets built in to the markup. This reduces download size and the effort required to make a web page accessible. For these reasons, we would promote the use of such markup over the ARIA approach.
The assumption was that native mechanisms would enrich the vocabulary of the
language, thus rendering ARIA increasingly unnecessary. As Derek
Featherstone has stated, "ARIA is designed to provide accessibility at a
technical level - what you might call 'programmatic accessibility' - where it
doesn't already exist". Longdesc
exists.
HTML does not require a bridging technology to provide host language long
description functionality for images as longdesc
already provides it
natively.
The fact that ARIA is a bridging technology and HTML5 should have built-in
native semantic features was successful
rationale used to keep <figure>
, <aside>
,
<details>
, and hidden=""
in HTML5. The decisions on
those Issues set precedent that native HTML is preferred over a ARIA, a bridging
technology.
Side-streaming accessibility technical requirements into an "Accessible Rich Internet Applications" specification is not a workable, long-term solution. The more content authors and application developers have to think specially about something called "accessibility", the more it will remain unimplemented in at least a sizable proportion of cases. To succeed, it really has to be core.
In fact 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.
As Karl Groves illuminated in his article "Confusion over HTML5 & WAI-ARIA",
The HTML specification is the shortest path to true accessibility...
WAI ARIA should only be used as a last resort when content can’t be made accessible using the host language.
Obsoleting longdesc and resorting to a separate bolt-on language by importing ARIA to provide equitable content to users would not only be a giant step backwards but a disgrace to the language. It would shift responsibility and segregate requirements into a corner labeled "accessibility".
Semantics
longdesc
strengthens the language. A longdesc
's
purpose is to provide a long description.
In contrast Henri Sivonen has stated,
the whole point of ARIA is to make semantic abuse accessible as an afterthought.
In other words ARIA is bandage meant to patch.
It is perhaps Ian Hickson who states the case best when he says that ARIA,
is not intended for use by authors who are trying to convey the very semantics that HTML can already convey.
HTML has native, built-in long description semantics with longdesc
.
Keeping it core to the language keeps valuable semantics in HTML. It provides
forethought, which thereby reduces the need for ARIA to be used as an accessibility
afterthought. The idea of HTML obsoleting longdesc
, a native semantic attribute, and 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 further rationale regarding semantics, please refer to my objection to the Zero Edit/Obsolete proposal.
Attempts to Reinvent the Wheel
This proposed replacement for longdesc
attempts to duplicate a
basic method that has already previously been created.
This proposed replacement is new and more complicated syntax for the same thing, or for a limited subset as it restricts the description to be on the same page.
Lacks Backwards Compatibility
aria-describedby
and hidden
are new. They have no
legacy or provenance. Whereas, longdesc
has legacy content and legacy
support.
Expecting authors to rewrite their content in order to support a technique that (a) does not work for authors or users, (b) reinvents the wheel, (c) lacks vendor support, (d) attempts to obsolete vital core host language semantics with a bridging technology, and (e) is simply a cumbersome "hack", is nonsensical and totally unrealistic : such attempts will serve only to infuriate and alienate both those authors and the accessibility community as a whole.
It is much less invasive to make longdesc
fully conforming. This
approach removes an illogical undue burden and will be acceptable to authors and
organizations that have made investments in the use of longdesc.
This
attribute has made content accessible to users on company, organizational,
governmental, educational, and personal sites throughout the world. It is
implemented in user agents,
authoring
tools, and assistive technology.
Content owners should not have to re-author content, already being delivered to
legacy devices as well as to today's leading-edge browsers and assistive
technology, in order for it to be valid and accessible HTML5.
Longdesc
-related features in existing authoring tools should
continue to output valid content : both authors and users have perfectly reasonable
expectations that longdesc
will continue to be supported by existing
tools, and will continue to have its current (i.e., intended) effect in existing
content.
Obsoleting longdesc
would result in mixed messages between existing
documents and HTML5. Such messages can serve only to confuse. Those who encounter
the copious array of books, tutorials, guidelines, laws,
policies and standards that have already recognized longdesc
's
importance to accessibility will expect longdesc
to continue to
function as described. Materials such as these have a way of living on; they will
not be obsoleted in the foreseeable future, and therefore neither must
longdesc
.
No Evidence of Improvement
No evidence has been presented that aria-describedby
or
aria-describedby/hidden=""
produces more accessible content for long
descriptions than longdesc
or that more authors would use it
correctly.
Expanding longdesc
Use
The
Keep the longdesc
attribute for the img
element
deprecated proposal states,
The aria-describedby attribute designed by WAI has several advantages over the longdesc attribute. The first one is that it is much more generic than longdesc. Longdesc is only available on <img> and the various frame elements. Aria-describedby on the other hand is allowed to be used on any HTML element
No decisive use cases based on real world examples have been presented that long descriptions are needed on other elements. This supposition has no concrete evidence.
No evidence has been presented that a generic container is well suited to a
DOM-based language (as HTML has indeed become in most practice) because it isn't
clear what APIs should be available (it makes sense to be able to access the
longdesc
programmatically for an image, but for audio or a plugin
there are different things you may want).
However, after it is reinstated in HTML, if use cases are presented, the
longdesc
attribute could very well fulfill those use cases by being
made a valid attribute on elements that need a semantic, programmatic determinable
long description or if warranted by being made a global attribute. This would
enable developers of tools producing HTML to use the same native HTML mechanism for
adding descriptions.
In fact, a FireFox browser vendor responded to a question asking, "Would it be
possible to make longdesc
a global attribute?" by saying, "This is
software, anything is possible".
Conclusion
I object to this proposal because it is misleading and fails to meet
requirements. It does not fulfill use cases. "Hacking" away with
aria-describedby
and hidden
is a retrograde "solution"
that doesn't work in practice for authors or users. It reinvents the wheel, lacks
vendor support, and backwards compatibility. It attempts to obsolete vital core
host language semantics with a bridging technology.
The Include
longdesc
in HTML5 Change Proposal as well as my objection to the
Zero Edit/Obsolete proposal provides further rationale for this objection and
explains how longdesc
solves problems and makes things better.
People with disabilities would be the losers if longdesc
were
removed from HTML in favor of this proposal.