Re: Drop longdesc, get aria-describedat?

On Tue, 13 Mar 2012 23:19:47 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Tue, Mar 13, 2012 at 6:08 PM, Charles McCathieNevile
>> <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>:
>> And for reasons outlined below, the implementor needs to think a little  
>> on their own...
>
> That's actually the problem: the more we leave to the implementer to
> think about, the less interoperable the implementations become and the
> less likely it will be a useful attribute.

Yeah, it ends up as a judgement call (like so much else of what we do,  
despite our claims to the contrary). To the extent that implementors make  
*bad* (as opposed to "not the best possible") decisions without being  
prepared to recognise and fix errors, it reduces the usefulness of the  
attribute.

>>>> 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)
>>
>> I wrote the TellMeMore extension ... 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).
>
> I'm not sure a visual indicator that is forced to be on by the
> browsers is acceptable to publishers.

I'm sure it isn't. I am talking about functionality I think *shoud be*  
available, that *allows* a user to force the indicator.

>>>>  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™)
>
> Do you mean by "inlining" to explicitly display it on the page?

Yep.

> I.e. do you mean that the linked resource would be pulled into the
> page and displayed inline? I don't actually think anyone is
> suggesting that...

I think there was a suggestion that it could be an optional way of doing  
things. I don't think it should be done in general, but the world is a big  
and complex place and making it "illegal" seems like a pointless  
restriction to me. (Let's assume for the sake of argument that I made up  
the suggestion now, unless whoever I copied it from wants to claim it).

>>>>  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/...
>
> As the long description would be behind a URL, I would expect there to
> be a HTML page behind the URL. Should that be prescribed?

I don't think so. I can imagine a world where it makes perfectly good  
sense to put SVG behind the URI. Or smething else. In practice, it is  
likely to be most useful as HTML. On the other hand, if you have a choice  
between a PDF with moderately bad accessibility, or nothing, I don't think  
we should say "don't put the PDF there".

>>>>  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".
>
> In the normative text, there are things we cannot say, of course. But
> there can be recommendations.

Yep.

> I've seen the problems of leaving too much interpretation to the
> browsers: ... The more that we can prescribe /
> recommend, the better for usability and accessibility.

So long as we get the balance right. The HTML 4 spec managed to make a  
dog's breakfast of accesskey for about a decade, with one simple,  
unnecessary, and unfortunately ill-considered recommendation of UI  
implementation,

>> 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.
>
> Only if you want the browsers to compete with each other on these  
> features.

Yes. And I certainly do - among other reasons because I see the benefits  
of competition-driven innovation and improvement as far outwieghing the  
minor drawback that people need to learn browser-specific behaviour.  
Currently we're "stumbling blind" in our ability to make good UI for this,  
and people need to learn a whole lot of browser-specific stuff to swap  
 from one to the other anyway.

> I agree that traditionally rendering issues have been left to the
> browsers to solve and that's why they are not normative in
> specifications. It will lead to diverging features and confused users
> that cannot find their features in the same places everywhere. Thus,
> the least we can do is recommend how to implement the rendering for
> each one of these user types.

I think we're at a stage where we should still be pretty humble about our  
ability to make really good recommendations.

>>> 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.
>
> OK, I'm happy to discuss the best means of providing rendered
> indications of availability of a descriptive resource link. That's a
> good discussion to have.

(I'll take this to a separate thread - this one is already eating my  
email...)

The rest of this is history wars I guess...

>>>>> I don't think we've asked any browser or screenreader devs yet  
>>>>> whether they'd resist an aria-describedat attribute.

> Hopefully the browser vendors are active in the forums that we're
> addressing here....

Yes. I believe that at the very least they are aware of the dicsussions

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

>>> @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.
>
> Because it wasn't specified what to do with it.

I don't think that is true. It wasn't well specified what to do with a lot  
of HTML 4, and it mostly worked. There was a suggestion about accesskey,  
and once everyone ignored it and did something else accesskey started to  
prove its value.

>>> 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.
>
> Ok, let's start it then. :-)

Actually, I did, a few years ago. Until there is some commitment to work  
on this, there is no point dedicating more resources to further spec work,  
however important the feature is.

...
>>>> 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...
>
> The new attribute would be applied to more elements than just <img>.
> Thus it's not reinventing the wheel.

There's no barrier to simply applying longdesc to more elements, if that's  
the key difference. (HTML 4 applied it to more elements already).

> As for the name: I'm really not that fussed.

I'm not that fussed either. The name has value because it leverages  
existing work that is good, and baggage because not all the legacy was  
that good. Whatever gets the problem solved in actual products actual  
users have is what I am prepared to spend time on.

cheers

-- 
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 Thursday, 15 March 2012 14:51:00 UTC