Re: Response to: ChangeProposals/DeprecateLongdesc

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