Re: Drop longdesc, get aria-describedat?

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)

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.

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...

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...

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.

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?  
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/)

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

JF

Received on Tuesday, 13 March 2012 01:27:01 UTC