Re: Drop longdesc, get aria-describedat?

On Tue, Mar 13, 2012 at 6:40 PM, John Foliot <john@foliot.ca> wrote:
>>
>> I've never seen progress being made by holding on to the past. That
>> cowpath is not one that is working, so I don't know why you're
>> clinging to it.
>
> Because it is working Silvia, despite the protestations of Hixie, Matt
> Turvey and others, it is seeing continued adoption, emergent author tools,
> jQuery plugins and browser extensions, and it has strong and robust support
> in the single largest screen-reader on the market. That the engineers behind
> Web-Kit, Gecko and other browser engines have not spent the time and effort
> to do something useful is a sad state of affairs, but it has not held back
> the usage or support from other quarters and other User Agents.

Since IE is interpreting the text inside the @longdesc attribute as
text and not as a link, it's not working, no matter whether
screenreaders can re-interpret that text and do other things with it.
IE is your biggest proof that browser vendors are not uniformly
interpreting the spec. And I got that from Steve and not for the
WHATWG. ;-)


>> This has nothing to do with the future: this is about how to deal with
>> the past. There are other means of dealing with this. As tools
>> implement support for a new attribute, they can continue to support
>> the old attribute or even create methods that automatically move
>> values from one to the other depending on what was authored.
>
> No argument. But to achieve what you have described we cannot Obsolete
> @longdesc today. It needs to be retained in HTML5 to do what you have
> proposed, and any discussion that heads in another direction will result in
> a failure to create a graceful "hand-off" path.

I am not arguing about obsoleting @longdesc now. I'd be happy with
whatever we do with @longdesc. I just believe that it hasn't served us
well and that a clean slate with applications to many other elements
will likely get us further in what we really want to achieve.


> Once again, it is outside of the scope of the HTML5 spec to prescribe UA
> interactions:
>
>        "This specification is limited to providing a semantic-level markup
> language and associated semantic-level scripting APIs for authoring
> accessible pages on the Web ranging from static documents to dynamic
> applications.
>
>        The scope of this specification does not include providing
> mechanisms for media-specific customization of presentation (although
> default rendering rules for Web browsers are included at the end of this
> specification, and several mechanisms for hooking into CSS are provided as
> part of the language).
>
>        The scope of this specification is not to describe an entire
> operating system. In particular, hardware configuration software, image
> manipulation tools, and applications that users would be expected to use
> with high-end workstations on a daily basis are out of scope."
> http://www.w3.org/TR/2011/WD-html5-20110525/introduction.html#scope

I know, but it doesn't stop us from providing the necessary
information elsewhere, or in non-normative text. Even if it is
provided consistently in bug reports to all browsers - that would be
better than leaving it completely open to interpretation and therefore
to misinterpretation.

>> Anyway, I think we should write a spec and start shopping it around
>> with browser developers to get some feedback and see if there is will
>> to implement. Whether we call that attribute @aria-longdesc or
>> @aria-describedat or just extend the existing @longdesc to video and
>> audio and update its spec (which I frankly think is the maddest path
>> of them all) doesn't really matter - a problem needs to be addressed.
>
> Agreed, to the extent that we need to see what, if anything, the mainstream
> browsers are prepared to support. To date, the response has been - uh,
> nothing.

I'll ask those people that I know care. We'll see what happens....

Cheers,
Silvia.

Received on Tuesday, 13 March 2012 22:30:52 UTC