Re: Drop longdesc, get aria-describedat?

Quoting Silvia Pfeiffer <silviapfeiffer1@gmail.com>:

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

Ah, but what you got is how the value for @longdesc was being reported  
to the Accessibility API. What we are getting from User-Agents that  
support @longdesc is not resulting output from the AAPI, but rather  
directly from a DOM query, which I would argue is a better solution:

1) 1 less "step" between authored code and rendering = less complexity.

2) DOM querying avoids the need for an AAPI-aware software tool.  
Currently all of the browser plugins and extensions that are emerging  
as proof of concept (or better) for @longdesc do not query the AAPI,  
but rather the DOM. This is an even more "Universal Design" support  
mechanism, as the majority of users do not have AAPI-aware tools  
(which today is pretty much restricted to screen readers).

There is an old expression that suggests that when all you have is a  
hammer, every problem looks like a nail. Today, too many people see  
ARIA as that magic hammer, which will be able to solve all  
accessibility problems.  If the browsers can show that they will  
actually take and use AAPI data and do something useful then I would  
be more inclined to believe that an aria-solution for this problem  
would be a Universally Designed solution. But for so long as this is  
not the case, ARIA really only solves "some" problems for "some" users.


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

The subject line of this thread would counter that assertion.

I have suggested more than once that de-linking the fate of @longdesc  
from how to move forward with a useful ARIA attribute that would  
extend the same or similar functionality is an important step. Sadly  
however there is more than one agent out there who seeks to use the  
introduction of a new ARIA attribute as "Proof" that @longdesc needs  
to be eliminated, which is both antagonistic and counter to progress.   
Yet none-the-less I now find that I have to write a counter proposal  
for Issue 204...



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

No argument again, but I think we've (I've) been pretty consistent on  
describing the functional requirements. I have also provided written  
suggestions and had face-to-face discussions (TPAC '11) with browser  
vendors about interaction patterns and related ideas.

If you believe that the Functional Requirements needed are unclear or  
require further information, I would welcome input there (as I suspect  
would others). I could even see value in describing/suggesting some  
practical ways of implementing the FR, but respect that User Agents  
need latitude in implementations. The best example is your suggestion  
of using the "Contextual Menu", which I am unaware of existing in any  
mobile browsing solution today (and I've actually tested quite a few  
mobile browsers: I could ask PPK if he is aware as he has tested even  
more).

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

Many hands make light work, and it is appreciated if you can get some  
support for forward movement.

cheers!

JF

Received on Tuesday, 13 March 2012 23:11:00 UTC