- From: Janina Sajka <janina@rednote.net>
- Date: Wed, 24 Aug 2011 10:53:22 -0400
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: "E.J. Zufelt" <everett@zufelt.ca>, public-html-a11y@w3.org
Hi, Silvia: Silvia Pfeiffer writes: > On Wed, Aug 24, 2011 at 8:49 AM, E.J. Zufelt <everett@zufelt.ca> wrote: > > On 2011-08-23, at 6:31 PM, Janina Sajka wrote: > > > >> Silvia Pfeiffer writes: > >>> The problem of aria-describedby automatically starting to read out the > >>> description is not as a big a problem as you make it out to be. Every > >>> screen reader has a key that stops the screen reader from continuing > >>> to read what it is currently reading ... > >> > >> > >> And then what? Are we to abandon reading anything else on the page? If > >> we resume, where do we resume? Right in the middle of that > >> long-description that wasn't so interesting and caused us to stop speech > >> in the first instance? > >> > >> No, Silvia, it won't work that way. > > > > As a screen-reader user my first response was to agree with Silvia. I * never * use continuous reading on a web page, I rarely use continuous reading in any document. However, I do recognize that continuous reading is used by some screen-reader users. > > > > If I were to run into a long description that bored me I would likely (JAWS): > > > > 1. press the down arrow key a couple of times until I was past the description and then resume continuous reading, or > > > > 2. Press the read next paragraph key combination and then, presuming I was past the description, resume continuous reading. > > > > However, I would never be quite sure that I had actually finished w/ the long description, and that I wasn't skipping to far and missing important or potentially interesting information. > > > That is indeed the interaction that I meant and IIUC what Janina > termed "Escapable Structure". > Are you sure this is what you mean? You want screen reader users to ""not be quite sure" of where they are?" That they're not "skipping too far and missing important, or potentially interesting information?" Is this your actual intent, or would you like to reconsider? Silvia, it seems you latched on to Everett's explanation of how he could handle being pulled into something he wasn't too interested in, but you glossed over the result. The result is not trivial. We want reliable results for our commands, not users floundering around, "not quite sure" of where they are. Indeed, I would ask Everett how, in the scenario he paints, how he knows he's "run into a long description." I understand he knows he's bored, but how does he know he's in a long description, and not just in the web page that everyone else sees? It's all rather imprecise when based on describedby. PS: This is not the DAISY "escapable structure," defined in ANSI z39.86. There's nothing imprecise about DAISY escapable structures, either in content markup, or in the user's ability to choose to read them (or not), and to escape reading them part way. In fact, we could term the TF backed longdesc markup an escapable structure. It meets all the requirements of Z39.86. The describedby approach does not. > Janina: I don't quite follow why what I suggested is a problem. Are > you taking the view of a person that is not interacting with the page > and therefore cannot press a button to go to the next element to be > read out? The way I see it is: > Silvia, my answer to you is found in your words immediately above. In the describedby approach there is no button that takes you out of the description and back to the page content that all users see. That command doesn't exist. Nor, is it clear how the user knows where they are in this approach. The content is being read automatically. The user didn't request it. How could the user know it's a long description and not just the page content that all users see. > with @aria-describedby the screenreader will start reading out the > long description to you and you have to actively interrupt it and move > on if you don't want it. > Or, perhaps you want the screen reader to say "long description of image?" Now we know? But, in that case, what does it say when describedby is used for one of its other legitimate uses? > in contrast, with @longdesc the screenreader mentions that a long > description is available and you have to actively press a button to > get it read out if you want it, then press another button to move on. > Exactly. This is appropriate. The user should always be in control, not the machine. Returning again to the definitions and the distinction between alt and longdesc, the former is auto read, and the latter is not by design. This design is based on user requirements. Why? Because it's simply not the case that longer descriptions are always read. They need to be there to be read when wanted, but the user shouldn't be forced to read anything--not even the rest of the page. Of course, there's nothing that prevents a screen reader from offering a configuration option to auto read longer descriptions in the case of our CP's approach. > >From where I stand, they are two different means of interacting and > some people may prefer one over the other. I cannot in general say > though that one is better than the other. They both have their merits. > > Where am I wrong? > Let me ask you. When you encounter a page with 4 or 5 images, perhaps thumbnails of famous paintings, do you always always pause to enlarge them? Do you always take 30-40 seconds to consider each of them in turn? Because that's what you're doing to the screen reader user by insisting on automatic reading of longer descriptions. Or, do you appreciate the fact that you have a choice? Perhaps, indeed my strong supposition, is you appreciate this choice so much that you take it for granted.. I'd appreciate the same consideration. Janina > Thanks for helping me understand. > > Cheers, > Silvia. -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Chair, Open Accessibility janina@a11y.org Linux Foundation http://a11y.org Chair, Protocols & Formats Web Accessibility Initiative http://www.w3.org/wai/pf World Wide Web Consortium (W3C)
Received on Wednesday, 24 August 2011 14:53:58 UTC