can we get the browser to contextualize focus?

I think that Greg Lowney is onto something, here.  And I think
that the browser could possibly do something about it.

This has to do with reflecting focus on the screen, and managing
sensitive regions for clicking when the document defines a label
for a control.  The issue is actually broader, but the form
control label is where this thread started.

One of the ongoing cognitive problems with GUIs is the way in
some UIs the sensitive item is a checkbox or bullet, and in
others it is the text, and in others there are redundant links to
the same action attached to the bullet and a text range in the
text that goes with the bullet.  This is a mess.  

Giving the speech-rendering tool programmatic access is a
marvelous feature.  But it is not a complete solution.  We need
to make sure that the way the focus or state information is
handled on the screen and through the API are both there and both
communicate well.

For motor-impaired users, it is beneficial to give them a fat
target, a sensitive region which a) encompasses both the control
proper and any defined label [or equivalent -- to be expanded]
and b) has suitably fat guardbands (non-sensitive dead zones
between sensitive regions) between it and adjacent sensitive
regions.

Visual highlighting of the label when the control has focus would
also make the congnitive situation clearer.  That is what
label-for is for.  Its role is "If you have any doubt about what
this control is for, read the label."

There are two sides to this point: display and control.  I have
tried to give a description of the usability demand for the control
side above.  On the display side, I want to expand a bit.

There are two things to talk about: perturbations in the display,
and the "immediate logical neighborhood of the focused element."
We are already familiar with the idea of "the logical
neighborhood of an element" through the example of the context
for a TD table cell, as exposed in the work on the SCOPE and
HEADERS attributes in HTML 4.  But this phenomenon doesn't just
happen in tables.  The cases that are not working today include
many such context relationships.  A DD element has a context in
the form of its governing DT element.  A LI element may have a
context in the form of an LH element or TITLE attribute on the
enclosing UL construct.  In the particular case of form controls,
the label for a control is clearly part of the immediate logical
neighborhood of its associated form control.  Providing a
perturbation of the presentation properties of the label which is
coordinated with the onfocus event for the control element would
seem to be a more understandable and usable interface.

Then the question becomes, how do we define the immediate logical
context of an element?  And how should the appropriate
perturbations of context presentation properties be decided and
applied?

By this means, it should be possible, when a form control gains
focus, to get the label read by a screen reader which reads the
screen.  That is a beneficial outcome.  But that is not the only
reason we should look at highlighting the label for a form
control and comparable context setting items across a broad
spectrum of elements best understood in context.  The users with
low vision or cognitive issues also benefit significantly.

Al

----- Forwarded message from Greg Lowney -----

From greglo@microsoft.com  Wed Oct  7 21:25:12 1998
Message-ID: <4FD6422BE942D111908D00805F3158DF08CF9292@RED-MSG-52>
From: Greg Lowney <greglo@microsoft.com>
To: "Charles (Chuck) Oppermann" <chuckop@microsoft.com>,
        Al Gilman
  <asgilman@access.digex.net>, w3c-wai-gl@w3.org
Subject: RE: potentially misinterpreted wording on label positioning
Date: Wed, 7 Oct 1998 18:24:41 -0700 
X-Mailer: Internet Mail Service (5.5.2232.9)

For blind access that is true, the LABEL element allows screen readers
identify the label of a control even if the two are spatially separated.
However, grouping them closely together helps people using magnifiers or who
have limited field of vision, and I would assume that it also helps people
with some types of cognitive impairments.

		-----Original Message-----
		From:	Charles (Chuck) Oppermann
[mailto:chuckop@microsoft.com]
		Sent:	Wednesday, October 07, 1998 6:18 PM
		To:	Al Gilman; w3c-wai-gl@w3.org
		Subject:	RE: potentially misinterpreted wording on
label positioning

		Shouldn't a exception be made for labels using the <LABEL>
element?  That's
		the purpose of the element, to remove the need for user
agents and the
		accessibility aids that run on top of them to "figure out"
where the element
		is.

		With Internet Explorer 4.01 and Active Accessibility, if the
<LABEL> element
		is used, it doesn't matter what the visual appearance is -
the two elements
		are linked programmatically and the accessibility aid will
be aware of it.

		-----Original Message-----
		From: Al Gilman [mailto:asgilman@access.digex.net]
		Sent: Wednesday, October 07, 1998 6:11 PM
		To: w3c-wai-gl@w3.org
		Subject: potentially misinterpreted wording on label
positioning



		In Appendix C where it is talking about labels for form
elements, it says

		        15. A.12.4. For all form controls with labels,
ensure that the
		            label that is either:
		               o [239]immediately following its control on
the same line
		                 (allowing more than one control/label per
line).
		               o or [240]on the line before the control
(with only one
		                 label and one control per line).


		In the second list item [link 240] I would have taken this
to mean
		that the label is on one line, the control on the next.
That is
		not what you mean.  I think that fewer people will be
confused if
		you just make it parallel with the first list item

		               o or [240]on the same line but before the
control (with 
		                 only one label and one control per line).


		Actually, I would have listed this as the first choice...

		Al

----- End of forwarded message from Greg Lowney -----

Received on Thursday, 8 October 1998 10:24:11 UTC