Re: Drop longdesc, get aria-describedat?

On Tue, 13 Mar 2012 03:12:26 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

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

You mean Leif's comment there? I've seen those things in this discussion  
(which has cost far more time than *implementing* longdesc cost Opera)  
before.

And for reasons outlined below, the implementor needs to think a little on  
their own...

>> The requirements for what is needed from a user-perspective ...

>>  1. User Interaction: Discoverability (*all users* have the need to  
>> learn that there is supplemental data available)

Screen readers who implement this have added a vocal marker (much as they  
do for a link, when you come across it). I wrote the TellMeMore extension  
for Opera because it turns out context menu really isn't enough, and it  
provides an indication in the UI that there are longdescs present, along  
with a way to check the images and their longdesc (although it was a day  
of not very high-quality hacking, so it serves more as an illustration of  
an idea than a production-quality tool). What it doesn't do, but should,  
is allow the user to have an indication in the page itself, i.e. something  
like an overlay on the image or giving it a distinctive border... (that  
approach needs thinking through the options, because it has some  
interesting implications).

>>  2. User Interaction: User Choice (*all users* have the need to choose  
>> to consume or not consume the supplemental data)

Yep. I.e. the description should not, in a default setup, be inlined  
except on user request (should not must because there are some scenarios  
where inlining makes sense, but in the most part it is a Bad Idea™)

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

It needs to support rich media - oddly, probably including images. So it  
basically needs to be able to render HTML - a new frame/window/...

>>  4. User-Agent Support
...
> That's not concrete enough. If we say "discoverability", we have to
> say how.

Hmmm. We have to say things like "it needs to be obvious without  
inspecting the image".

The way a sighted user scans a page in a UI, the way a low vision user  
scans a page, the way a typical blind user scans a page are very  
different. The way a deaf-blind user scans a page is slightly different  
again. So we need to describe functional requirements without telling the  
User Agent exactly how to do this.

> Context menu is a good answer.

Wrong. It isn't easily discoverable. iCab's changed cursor is an  
indicator, but not, IMHO, enough for real benefit.

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

Leif is asking - that's where this thread came from.

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

Unfortunately not.

> There is a time for everything.

Indeed.

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

No, by and large the browsers didn't bother implementing anything. The  
screenreaders, whose user base has a very high level of value from it,  
eventually implemented it on their own. (An analogy from history is the  
header navigation - it was in Opera from the start, it took JAWS until the  
last decade to implement it even though the user base has a relatively  
high value from it, and in most browsers it still doesn't exist).

> We now understand the issues of @longdesc better and can much more
> clearly explain what the attribute needs to do.

Sure.

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

History doesn't make me as confident as you sound. But I'm really more  
interested in results than arguments, so if you have a browser supporting  
the idea of implementing something, I'll work to make sure there is a  
specification they like.

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

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

I hope so.

>> 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
...
> 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 the alternative is actually to reinvent the wheel, but change its  
name. If we have a good external reason to expect a different result,  
doing the same thing again makes sense, but expecting that a priori...

cheers

Chaals

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 13 March 2012 07:09:34 UTC