W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2011

Re: Response to: ChangeProposals/DeprecateLongdesc

From: John Foliot <jfoliot@stanford.edu>
Date: Tue, 23 Aug 2011 19:55:57 -0700
Message-ID: <lsq2s84ftiiptytil8ishw1h.1314154557845@email.android.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-html-a11y@w3.org
Hi Silvia,

It has been repeatedly pointed out that HTML5 does not prescribe user-agent behavior: what I mentioned is what is currently emerging "in the wild", and based on feedback from the NVDA developers it seems that they could support that kind of interaction model, thus my suggestion. 

Screen readers that currently support @longdesc announce the presence of the link and await further interaction. I think the real key is the combination of both discoverability and choice. We generally have that today in supporting tools, but lack a similar combination in the mainstream browsers for other (non-screen reader) users - if I were to be in charge of designing a common interaction model, I would likely advocate something similar to what we can do with Opera with Chaals' Tell Me More plugin. That combination signals the presence of @longdesc in the browser chrome, and has the choosing interaction (switch) in the contextual menu. However if the browser developers came forward with other ideas that supported both discoverability and user-choice I think that would be positively evaluated.

As spec'd today, aria-describedby *is not supposed* to offer the second half of the equation - the option to choose to find out more (or not), which is the key flaw. Suggesting that users must deliberately silence extended descriptions each time is an ackward interaction pattern - it's a backward scenario. The use-case of the corporate logo in Laura's use-cases is a great example of why this interaction is important: a user may want to know the details of the logo once, but not on each page, thus rendering aria-describedby ineffective (and even harmful) here.

JF

John Foliot
Program Manager
Stanford Online Accessibility Program
http://soap.stanford.edu
Tel: 650-468-5785

+ sent from my Xoom tablet - Go Android! +

Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

>On Wed, Aug 24, 2011 at 9:00 AM, Janina Sajka <janina@rednote.net> wrote:
>> Silvia Pfeiffer writes:
>>> Note that your proposal strongly supports the move of @longdesc to the
>>> context menu, which in turn makes the availability of a @longdesc link
>>> much harder to discover for screen reader users because they have to
>>> open the context menu to find out, while @aria-describedby will just
>>> push the description at them. So, if anything, the discoverability
>>> argument is not going in your favor.
>>>
>>
>> This is not correct. It is expected AT will provide suitable mechanisms
>> to identify the availability of long desc, as indeed AT is able so to do
>> today as shown in the TF backed proposal:
>>
>> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation
>>
>> The actual point of providing longdesc via a mechanism like the context
>> menu is to allow any user, not just AT users, to access this content.
>> This was an oft repeated criticism in earlier discussions. While not an
>> a11y requirement,it's certainly a usage the TF does not oppose. If the
>> WG wants longdesc to be sharable across all users, more power to the WG,
>> the TF has never objected to that.
>
>OK, can we make sure that the proposal explains that longdesc's
>availability should both be announced by screen readers upon reaching
>the image and be in the context menu? This wasn't clear to me from
>reading the document.
>
>Cheers,
>Silvia.
Received on Wednesday, 24 August 2011 02:56:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:44 GMT