Re: Drop longdesc, get aria-describedat?

On Tue, Mar 13, 2012 at 6:08 PM, Charles McCathieNevile
<chaals@opera.com> wrote:
> 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 think Leif's comments go too far. I'd be a bit more restrictive as I
said in reply to his email.

> I've seen those things in this discussion
> (which has cost far more time than *implementing* longdesc cost Opera)
> before.

It'd be funny if it wasn't so sad. :-)


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

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

I'm not sure a visual indicator that is forced to be on by the
browsers is acceptable to publishers. We'd then need to introduce a
CSS property to change it/turn it off for Web pages that don't want
this kind of indication. Just like you can change/turn off indications
of a URL being a link.

Actually, thinking about this a bit further - there is currently a
suggestion to introduce @href as a common attribute on all elements.
While that is a more generic approach, it would likely lead to the
same uses: namely to attach another Web resource to an element to
describe its content further. It has the same problem of visual
presentation.


>>>  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? 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...
but I'm likely misunderstanding...


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


>>>  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. I've seen the problems of leaving too
much interpretation to the browsers: e.g. the differences in the video
controls between the browsers are staggering. So much so that we need
JavaScript plugins to make controls that look and behave the same
across browsers. That's more of a nuisance than a blessing in my eyes.
In particular since an advantage of the browser-rendered controls is
that we can register a few bugs on each browser and get it solved once
and for all, rather than having to chase each one of the custom
controls that Web publishers provide. The more that we can prescribe /
recommend, the better for usability and accessibility.


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

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.


>> 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.
What are the options?
* changed cursor
* visual indicator on the rendered content - how can we do that subtly
and such that it works on different elements?
* visual indicator somewhere else in the browser (similar to
TellMeMore) - this can be easily missed
* context menu and property inspector - I think these are no-brainers
and should be done
* audible indication - that would work for screenreader, but it
wouldn't work in the general case
* creating a link underneath the picture - that is meddling with the
page layout and not acceptable IMO
* ??


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

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


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

Because it wasn't specified what to do with it.

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

That's no different to most aria attributes.


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

Ok, let's start it then. :-)

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

The new attribute would be applied to more elements than just <img>.
Thus it's not reinventing the wheel.

As for the name: I'm really not that fussed. I have
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12964 to worry about.

Regards,
Silvia.

Received on Tuesday, 13 March 2012 22:20:37 UTC