RE: describedBy and longdesc

WARNING:
This is a rant. If you don't want to read a rant, hit delete now and
thanks, bub-bye.

Leif Halvard Silli wrote:
>
> Charles McCathieNevile, Sat, 26 Mar 2011 11:23:07 -0400:
> > On Fri, 25 Mar 2011 22:34:27 -0400, Jonas Sicking wrote:
> >> On Fri, Mar 25, 2011 at 6:57 PM, Laura Carlson :
> 
> > aria-describedBy, if fixed, and generally applicable, would be better
> > than longdesc. I hope that in some time this will happen, and
> > longdesc will become obsolete.
> 
> I don't share this hope.
> I don't see this happen.
> Rant: I hope that aria-describedby becomes obsolete.

SETTING THE STAGE:

	"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."
- Ian Hickson 
http://lists.w3.org/Archives/Public/www-archive/2010Mar/0029.html 

	"The working group likes the idea of having built in semantics in
HTML... For these reasons, we would promote the use of such markup over
the ARIA approach."
- Al Gilman (former) Chair of the W3C Protocols and Formats Working Group 
http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html 


	"...the only credible alternatives I have seen... are a suggestion
to replace it with another attribute. With a new name. That does. THE.
SAME. THING.

So if we (the collective genius who produce HTML5 and all its alternates)
can't come up with any better ideas in a decade, maybe we're just not that
clever when faced with complex problems in accessibility. Or maybe
longdesc isn't that bad after all."
- Chaals McCathieNevile 
http://www.cssquirrel.com/blog/2010/08/16/comic-update-alone-in-the-pitch-
black-dark/#comment-32134 


> >
> > Which I think is the right approach.
> 
> I for my part agree with Laura that the @aria-describedAT proposal is
> an acknowledgement of @longdesc's unique features. I think we need
> accurately specified A11Y features. Allowing too much freedom soon ends
> up like a - ah - certain lottery. Thus it doesn't seem like the right
> approach is to overload @aria-describedby - or any other ARIA attribute
> - with multiple semantics.

+1 

I really don't think aria-describedby is broken, it does what it was
designed to do - nothing more, nothing less. Having to go back to ARIA and
introduce a new attribute that is essentially @longdesc in everything but
name is just plain silly IMHO. It is a retrograde move. It perpetuates the
idea that the content of @longdesc is for non-sighted users
(accessibility) only - as Ian states "ARIA is intended to only affect
accessibility API mappings (and thus ATs)." 

Yet one of the complaints we've repeatedly heard is that the text
contained in the page pointed to by @longdesc might be useful for sighted
users as well, that longer descriptions benefit more than just those who
are blind and using screen readers (AT), but that because there is no
visual indication that @longdesc content exists, it fails those users. It
also perpetuates the "black data" argument, because sighted authors won't
see their <strike>longdesc</strike> <ins>aria-described*</ins> efforts.

This is ludicrous! This line of discussion is not fixing any problems, it
is introducing new ones. It is suggesting to re-open a Candidate
Recommendation (ARIA 1.0) to either re-work an existing attribute, or
introduce a new one. It is breaking backward compatibility with an
existing 12 year old specification. It dogmatically rejects an existing
attribute in favor or creating a new attribute that does exactly what the
old attribute did. 

Why?

DESIGN PRINCIPLES OF HTML5:

	USERS:
We have an attribute. It does good things when used properly, and when
misused it is relatively benign. It works well today for users of most
commercial screen readers (80% rule), and can be used by sighted users who
choose to either use a browser that supports @longdesc natively (Opera,
iCab) or who wishes to install a plug-in or fine-tune their configuration
to access the content (Firefox plug in, Sean Hayes' recent MSDN blog post
for IE support) (20% rule). Or is the 80/20 rule only for those *without*
disabilities?

	AUTHORS:
We have increased author awareness of @longdesc. We have HTML WYSIWYG
editors today that allow authors to properly include @longdesc at the
authoring layer. We have professional content producers (ePub, DIAGRAM
Project) that want to use this attribute, and will in all likelihood use
it correctly (after all the digital ink that has been spilled on this
topic, I will bet a sizable sum of money on that).

	IMPLEMENTORS:
We have implementers who have dragged their feet on doing something useful
with @longdesc since 1999! And representatives of those user-agents
arguing for the removal of @longdesc from HTML5, without once stepping up
to the plate and tackling the alleged short-comings of the attribute. (Yet
other user-agents - screen readers - *do* do something useful with
@longdesc, so it's not like the attribute cannot be successfully supported
by user-agents...)

	CODE PURITY:
The simple fact today is that if you wish to author an otherwise
conformant HTML5 document, but then add @longdesc to an image in that
document, the following will happen:

	- the page will continue to render fine in all GUI browsers
	- the URL of the @longdesc attribute will be written to the DOM as
an attribute of the <img>
	- screen readers and other consuming user-agents that support
@longdesc today will have access to the long description. Simply put, it
still works.
	- HTML5 validators will through an error message.

	"A terrifyingly small percentage of the pages on the web pass a
validator. The far vast majority of pages doesn't even nest their tags
correctly. The sad truth is that while we can do what you suggest,
it's not going to have a big effect because people simply doesn't
consult validators to a large degree."
- Jonas Sicking
http://lists.w3.org/Archives/Public/public-html/2011Mar/0627.html 

'nuff said. 

JF

Received on Sunday, 27 March 2011 05:15:29 UTC