Re: Response to: ChangeProposals/DeprecateLongdesc

On Wed, Aug 24, 2011 at 12:55 PM, John Foliot <jfoliot@stanford.edu> wrote:
> 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.


If we completely disregard UA behavior for arguing this case, then
discoverability is not an argument either. I am just trying to point
out where I would see possible issues with your proposal.


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

I agree that the key difference between @aria-describedby and
@longdesc is what you call "choice": that the first follows the
push-model, while the second the pull-model ("choice"). I don't regard
it as a flaw for either of them - they just support different
interaction models and depending on who you are and your situation,
you prefer one or the other. It would almost be better if we just had
one mechanism to provide long descriptions (whichever of the two) and
then a browser preference to set whether you want the browser to push
the information at you (in the case of @longdesc that would mean:
downloading the URL and starting to read it out) or pulling the
information (in the case of @aria-describedby that would mean: waiting
for a user interaction to read the referenced section(s)).


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

I agree that there are indeed situations where you want one
interaction pattern over the other. Maybe you could have a browser
setting that automatically read out the content of the referenced
fragment/document only the first time in one browser session and then
not again unless the user actively asks for it.

I guess what I am saying more and more is that no matter which markup
solution we choose, it eventually comes down to what user interaction
the browsers implement and that it is possible to implement all the
user interaction behaviours that are being discussed with either of
these two approaches, thus making any arguments about the different
behavious that they currently support insubstantial.

Regards,
Silvia.

Received on Wednesday, 24 August 2011 04:45:41 UTC