Re: WD#177: User control of current focus change and notification.

originally attempted to send prior to 20 january telecon; resent following

aloha, jon!

my lingering concerns have to do with focus...    in particular, actionable
focus...  while it is true that, in the GUI environment, any adaptive
technology needs to establish focus when a new dialog or window is spawned, the
problems david and i have been recounting to the WG for the past few months
occur when the spawned item (be it a dialog box or system message) is generated
with focus placed upon an actionable default...  in the case of the "do you
want to install now" dialog that david has used as an illustration, or an
important one-time system message, which is generated with focus already upon a
focusable item, one can unwittingly either cause the installation routine to
begin, or cause the system message to clear, leaving the user with a disability
without any knowledge that the message was generated in the first place,
especially as the spacebar (at least in the Windows environment) activates
button controls...

this is the problem with demanding that everything be generated with focus
already established in an actionable item or on the first active element of a
page...  if a UA is forced to automatically establish focus on a page, once it
is rendered, then the user can no longer use the "Applications" key (on a
Windows 95 keyboard) or the Shift+F10 key combination to obtain the extended
context menu that is only available via the 2 keystrokes listed above or by
right mouse clicking on a blank, non-active area of the rendered document... 
likewise, when a system message, in which focus has been automatically placed
upon an actionable item, is generated, interrupting the user's interaction with
another application, keystrokes intended by the user for the interrupted
application can (and often are) received by the interrupting application... 
while i recognize the general utility of default actions in such contexts, for
the blind user, in particular, the automatic placement of focus upon an
actionable item can lead to anything, from a mild annoyance (accepting a cookie
one didn't intend to accept), to potential disaster (causing an installation
routine to begin when a "download complete" dialog box is generated, which
causes the system to crash due to limited resources, or hiding system messages
and warnings from the user, simply because his or her screen reader was still
echoing what he or she was typing at the time the error message was
generated...

this is, in my mind, at the very least a P2 issue, although i would (and will)
argue vociferously that it is a P1 issue, as it involves access to content,
functionality, and UI controls that is being denied to a certain class of
user...

as regards Issue #177, there are 2 issues at play:

1. should a UA be required to establish focus upon the first actionable item
when it renders document source?  while such action would clearly benefit
certain classes of users, it would also clearly harm others...  the solution,
therefore, would be to allow the user the ability to configure whether or not
the UA will establish focus upon the first actionable item contained in the
document being rendered...  such a configuration checkpoint is, indubitably,
Priority 1

2. should the user be allowed to substitute a device-independent alert
mechanism which would keep the UA from automatically stealing focus from
whatever other application the user is running at the time, in order to present
the user with a prompt, an alert, an error, or some other form of actionable UI
control?  of course, the user wouldn't be limited to only one such alert
mechanism (i.e. the playing of a sound, the flashing of the screen, the
generation of the UI control, etc.)

the question isn't one of access to the contents of the message (although that
is equally important) -- it is a question of efficaciously alerting the user
that such a message exists, for if a message is generated in an accessible
manner, but is inadvertently cleared by the user before his or her AT has
alerted him or her that the message has been generated, what does it matter
that the message itself was accessible?  it has disappeared, perhaps never to
recur, leaving the user uninformed and unaware of what has transpired... 
there's more to the accessibility of messages and dialogs than simply conveying
the information they contain in a device-independent and accessible manner...

like david, i eagerly await ian's review of the UAAG with these issues in mind,
but pending the issuance of a revised draft, i'm not willing to sign off on
this issue as resolved to my satisfaction just yet...

gregory.

At 04:39 PM 1/19/00 -0600, you wrote:
>Gregory and David,
>I propose that we have captured the essence of the problem stated in issue
>WD#177 related to the focus and notification issues related to user agent
>spawned windows in checkpoint 4.15 Allow the user to control user agent
>initiated spawned viewports. [Priority 2].   I suggest that if you support
this
>view that the action item work Gregory is doing related to describing the
>problem and possible solutions should be placed in the techniques document.
>
>What do you think?
>
>Jon
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Chair, W3C WAI User Agent Working Group
>Division of Rehabilitation - Education Services
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: http://www.staff.uiuc.edu/~jongund
>WWW: http://www.w3.org/wai/ua
>
>

--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Thursday, 20 January 2000 16:17:42 UTC