- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 24 Aug 2011 14:40:42 +1000
- To: John Foliot <jfoliot@stanford.edu>
- Cc: public-html-a11y@w3.org
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