Re: label placement contradictions (X-posted)

Hi Al, yes, this is much of it, but, depending on the age of the screen
reader being used, it is actually worse than even you implied.  The thing
the screen reader user who is using an older screen reader also has to do
to read the label above the focus is to some how change reading sources.
One is tabbing to the items in focus with what could be called the
application cursor or whatever is following the focus.  But when one gets
to a focus area, it is then necessary to begin reading the text, with the
(mouse pointer or screen reader review) cursor either line by line, by
word, by character, etc. as you pointed out.  As one tabs to a new focus
area, the mouse pointer or screen reader review cursor is probably nowhere
near the area of the screen which currently has the focus.  In newer screen
readers, this is not a large problem although it is sometimes tricky.
there is, however, a reasonable expectation that one can route the mouse
cursor to the area of current focus.   In some older screen readers, this
is not nearly as easy.  Thus, when one tabs to some area of focus and then
wants to read the line above that focus, one has to first find the text in
question from perhaps a good ways away.  After reading all the text
necessary to allow one to discover where they are and where the focus is,
it is likely that most persons will have their concentration totally
shattered and they will be lucky if they can even remember what they were
looking for in the first place.

At 01:44 PM 6/14/99 -0400, Al Gilman wrote:
>Putting a control label above the control has serious problems for users of
>older screen readers.  This is only marginally acceptable, and then only if
>there is no more than one control on line following label.
>
>Expansion:  The first-level of display scope in the screen reader is the
>highlighted text of the control with focus.  In some browsers this will
>include the label.  That is good style.  The label should share the
>highlight when a control gains focus.  The choices of reading scopes in the
>screen reader are roughly: the screen reader reads all in document
>serially, just the current line, or just the current
>focus-or-other-highlight.  To get from a checkbox to the label in the
>_previous_ line the user of the screen reader has to back up _twice_ in
>searching for better context.  Once to read the whole line, and then to
>read more than the current line.  Checking the previous line will be an
>arcane trick of the trade.  Next natural level of retreat above "read the
>whole line" is to start over at the top.
>
>A really bad scenario is the defacto table with multiple labels associated
>with multiple controls by layout artifacts.
>
>Neal, have I got this pretty much straight?
>
>Forcing the label to come before a checkbox or radio button has serious
>drawbacks in terms of visual values.  Lining up a set of parallel
>clickables in a column aids usability.  We need to compromise better here.
>Consider FatLinks in User Agent as a better fix.
>
>Steve McCaffrey is interested in accessible forms.  Please get comments on
>examples from him and Gregory Rosmaita before finalizing any adjustments or
>interpretations of the guidance in this area.
>
>Al
>
>At 04:38 PM 6/13/99 -0400, Charles McCathieNevile wrote:
>>Cross posted wo WAI GL and WAI EO.
>>
>>I agree with Len. I think we would be better off requiring consistent
>>positioning. The checkpoint itself requires proper positioning, but hte
>>explanatory text says the the label must be above or before the control.
>>
>>Charles McCN
>>
>>On Sun, 13 Jun 1999, Leonard R. Kasday wrote:
>>
>>  Checkpoint 10.2 has labels preceding fields, which make obvious good sense
>>  for text fields.
>>  
>>  However, for radio buttons and checkboxes, which one can think of as
>>  "bullet" controls because they look like bullets, Chuck's curriculum
>>  example has the label following the controls.  See
>>  http://www.starlingweb.com/wai/three/sam75-0.htm
>>  
>>  Question: do we change the checkpoint or Chuck's example?
>>  
>>  I think we should consider switching to what Chuck has for bullet style
>>  controls.
>> 


Neal Ewers
Trace Research and Development Center
5901 Research Park Blvd.
Madison, WI 53719
Phone: (608) 263-5485
FAX: (608) 262-8848
E-mail:  ewers@tracecenter.org
Web site: http://www.trace.wisc.edu

Received on Monday, 14 June 1999 14:56:44 UTC