Re: Drop longdesc, get aria-describedat?

On Tue, Mar 13, 2012 at 12:26 PM, John Foliot <john@foliot.ca> wrote:
> Quoting Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
>>
>>
>> The ePub spec is indeed quite a good start. I'd like to see
>> requirements on what the browser is required to do with the attribute,
>> e.g. the list stated in https://bugs.webkit.org/show_bug.cgi?id=10448.
>
>
> Hi Silvia,
>
> The requirements for what is needed from a user-perspective have been
> clearly articulate numerous times before.  I recapped them in my initial
> response to Jonas Sicking last fall:
>
>  1. User Interaction: Discoverability (*all users* have the need to learn
> that there is supplemental data available)
>  2. User Interaction: User Choice (*all users* have the need to choose to
> consume or not consume the supplemental data)
>  3. Preservation of HTML Semantics and Richness (flattened or string text is
> insufficient, as there is a need to support lists, tables, paragraphs and
> headings at an absolute minimum)
>  4. User-Agent Support (this is where, currently, the disconnect and
> breakage occurs)

That's not concrete enough. If we say "discoverability", we have to
say how. Context menu is a good answer.


> I urge you to read that wiki page in full.
>  (http://www.w3.org/wiki/A11yTF/longdescresponse)
>
> I share Chaals' frustration in that we've gone over all of this multiple
> times already. "Asked and answered" as they say in court.
>
>
>>
>> I don't think we've asked any browser or screenreader devs yet whether
>> they'd resist an aria-describedat attribute.
>
>
> Given that most browser vendors have not lent support to @longdec over the
> past 10+ years, I remain suspicious that they will do anything more today
> with a new attribute that will have essentially the same functional
> requirements that @longdesc has had since it's inception at HTML4.


Frankly, that's rubbish. There is a time for everything. @longdesc was
apparently not sufficiently specified such that the browsers all
started implementing different support and the screenreaders had to
come up with tricks to make it work. Also, in the last years browsers
have implemented ARIA support so a lot more attention has gone to
accessibility. We now understand the issues of @longdesc better and
can much more clearly explain what the attribute needs to do. Frankly,
@longdesc is a lost battle and does not apply to new elements such as
video and audio, so IMO starting from a clean slate and putting our
effort behind that is bound to be much more successful.


> Remember as well that it is more than just browsers: there are also
> authoring tools that would need to be re-factored, educational materials
> that would need to be authored/re-authored and distributed (and taught).
> Software would also need to be updated, and often times due to financial
> conditions the most in need of the solutions are also those least able to
> purchase the latest-and-greatest, so uptake of new software will take time.
> (I know from internal data that we will need to be supporting IE8 with all
> mainstream screen readers for at least another 18 months - 2 years, and
> perhaps longer). Not everyone is downloading nightly builds of their
> favorite browser...

Sure: we got to start somewhere. EPUB is starting somewhere, too. For
video and audio elements we start from a clean slate, too. I think the
@longdesc experience is helpful in getting this implemented faster.


> All of this is a non-trivial work effort, with a tangible and significant
> cost associated to it.  Meanwhile we have some tools that *are* supporting
> @longdesc today, including the market-leading JAWs screen reader, so if we
> are to accept the "Pave the cow paths" mantra of old...

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.


> Further, pushing this type of functionality into the Accessibility APIs
> actively harms those users who would require this type of functionality, but
> are not using tools that require access to the Accessibility API. In other
> words, why does it have to travel from page to the end user via the AAPI,
> when in actual fact it would be more useful if it was transmitted directly
> from the DOM to the user-agents? Nobody has successfully explained why we
> need to add an additional layer of API processing here. It is a serious
> question.

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.


> Do we have any evidence that the browsers will do *anything* with ARIA
> attributes beside push them on to the AAPIs, for "AT" to deal with it?

That depends on what the spec tells them. If we want anything else to
happen, we have to explain that. Other uses won't just magically
appear.


> I have concrete proof that in at least one instance they won't in the form of
> how they are handling the HTML5 @required attribute in form inputs vs.
> aria-required="true". For while conceptually they should be *THE SAME
> THING*, they are not processed the same way, and in the case of Mozilla they
> have no intention of changing that disparity any time soon. (see:
> http://john.foliot.ca/required-inputs/)

If they are identical, why would you need two of them?


> The problem is, and remains, a User Agent problem, where a few 'bully' User
> Agents refuse to do anything useful with an attribute, while other User
> Agents do do something useful. If the major browsers are not going to
> actually provide some form of tangible support for a mechanism to provide
> longer textual descriptions upon request (and after providing a means to
> notify the user) then they should step aside and leave this problem to those
> who *WILL* do something. I have repeatedly suggested it's not the name of
> the attribute that matters, it's what User Agents do with it that counts

You can always do an implementation yourself and gain larger
"bully-power" - WebKit and Firefox are open source.


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.


Regards,
Silvia.

Received on Tuesday, 13 March 2012 02:13:18 UTC