RE: Agenda + [2.4] CORRECT version of 2.4 proposal

Andi wrote:

<blockquote>
- I think there is a problem with the way this is worded. I think this
is supposed to be about the reading order of the elements of a page when
they are rendered by a screen reader or some other technology that
renders the elements in a simple linear order. Is there anything that
really affects reading "order" except layout tables and JavaScript? I
don't know of any way to programmatically specify the reading order of
the elements.
</blockquote>

You're right, Andi-- what I had in mind when I came up with the wording
was the issue of reading order when content is rendered by a screen
reader, though there may be other user agents that raise similar issues
that I don't know about.

I was thinking of some of the problems I've run into with layout tables
that looked great but linearized in some really strange ways.  I That's
a problem that will probably die a natural death someday, even if not in
my lifetime.  But the replacement-- CSS positioning-- raises the same
possible problems because it *does* (or can) separate content and
structure from presentaition (even if the boundary gets blurred
sometimes).  Mostly that's a good thing for accessibility-- it means
that the visual display order and the auditory sequence can be different
and each be "tuned" to the needs of a different segment of the audience.
But the decoupling can be problematic if the order of the content in the
delivery unit doesn't work as a linear sequence-- even if the order in
the source follows the visual order.  

Experienced readers make a lot of judgments on the fly as they traverse
Web pages-- they decide to skip some things, zoom in on others, jump
from a column of text in an article to a sidebar or an image that
suddenly looks more interesting, etc.  For most users that's not only
not a problem-- it's part of the fun.  But they know when they're
jumping, and they can see where to go when they want to pick up reading
where they left off.  

This isn't so easy for people with distractability issues, of course,
and it's not so easy for people whose screen readers are reading along
just fine and then get shunted suddenly off into some other block of
material in mid-sentence-- it's experienced as an extreme change of
context.

Besides layout tables, Javascript, and CSS, there are also reading-order
issues with Flash and with PDF unless the PDF document is either
organized in a simple linear way or correctly tagged so that all the
content is contained within the structure; the first thing I see when I
download a PDF document from the Web is usually a dialog telling me that
Acrobat is bracing itself to deal with an untagged document and that
I'll need to leave it alone while it figures out how to infer reading
order from the document.  Reader 7 does a pretty good job of that
(thanks, Loretta!) most of the time, but sometimes it just can't do it
and I hear gobbledygook like the stuff I used to hear when JAWS 3.0 ran
into a multi-column layout.    Reading order is also an issue in MathML,
I think, although in a different way-- people need to be able to go back
and "chunk" the equations so they can get the order of operations right,
etc.  Neil Soyfer can say much more useful stuff about that than I can.
And Joe Clark has done some work on eye-movement during reading by
people with low vision; maybe he can help us think through this as well.

John




"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Andi Snow-Weaver
Sent: Wednesday, May 04, 2005 4:04 pm
To: w3c-wai-gl@w3.org
Subject: Re: Agenda + [2.4] CORRECT version of 2.4 proposal




Level 1 SC 2: "When content is arranged in a sequence that affects its
meaning, that sequence can be determined programmatically."

- I think there is a problem with the way this is worded. I think this
is supposed to be about the reading order of the elements of a page when
they are rendered by a screen reader or some other technology that
renders the elements in a simple linear order. Is there anything that
really affects reading "order" except layout tables and JavaScript? I
don't know of any way to programmatically specify the reading order of
the elements.
- For layout tables, the order is predetermined and the author has to
understand that and simply code the tables so that the content makes
sense when it is read in that predetermined reading order.
- And with content that is displayed due to a JavaScript executing, the
new content has to be located in the HTML code so that the screen reader
reads it correctly in the sequence. For example, if the content
displayed by a JavaScript is physically located in the HTML file at the
end of the file, the screen reader will not read it until it gets to the
end regardless of where the JavaScript caused it to be displayed on the
screen. This may make the page not understandable.
- I am struggling with how to generalize this. I want to say something
like "Order the elements of the delivery unit so that, when read
sequentially, any meaning conveyed by the visual presentation of the
delivery unit is maintained." But does this work in all technologies? I
think it works in PDF but what about other technologies like xForms?

Level 1 SC 3: "For each reference to another delivery unit, a title or
description of that delivery unit can be programatically determined.", I
have two questions:

-  this is already covered in GL 3.2 Level 2 SC 6. Are you proposing
that we have two success criteria that address this or are you proposing
that we remove the GL 3.2 success criteria?

- what is the rationale for moving this to Level 1?

Level 2 SC 1: "Documents that have five or more section headings and are
presented as a single delivery unit include a table of contents with
links to important sections of the document. " is not testable due to
the word "important". Suggest rewording as "Documents that have five or
more section headings and are presented as a single delivery unit
include a table of contents with links each section heading of the
document. "

Level 2 SC 3: "Blocks of repeated material are implemented so that they
can be bypassed by people who use assistive technology or who navigate
via keyboard or keyboard interface." needs some work to clarify where
the repeated material is. Navigation menus are not repeated within a
single page but this is what we want people to be able to skip. They are
repeated on each page of a "site". How about something like "Blocks of
material that are duplicated on the delivery units of a Web site domain
are implemented so that they can be bypassed by people who use assistive
technology or who navigate via keyboard or keyboard interface."

Level 3 SC 2: "Images have structure that users can access." is
technology dependent. If you have an image technology that supports
"structure", then Level 1 SC 1 applies.

Level 3 SC 4 and 5: I suggest using the word "organized" instead of
"divided". Divided implies (to me) that that there must be at least two
paragraphs or two headings when one might actually be enough for very
short texts.

I agree that "heading" is the right term but not because it is what is
used in HTML. It is the term used in English grammar. I wonder if this
will translate well to other languages.

Examples: I think the short titles of the examples should tie the
example back to the success criteria it is meant to illustrate. For
example, since # 6 is about reading order, something like "Sequential
reading order of an online newsletter". This is a general suggestion
that applies to all examples in the guidelines.

Andi
andisnow@us.ibm.com
IBM Accessibility Center
(512) 838-9903, http://www.ibm.com/able
Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo

Received on Wednesday, 4 May 2005 21:38:30 UTC