W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

[Action] Issue 443: Repair of device-dependent author-specified behavior.

From: Ian Jacobs <ij@w3.org>
Date: Wed, 21 Feb 2001 13:40:27 -0500
Message-ID: <3A940B9B.71156D77@w3.org>
To: w3c-wai-ua@w3.org

Per my action item assigned at the 15 February 2001
teleconference [1] about issue 443 [2], please consider this
proposal for which device-dependent repair requirements should
appear in UAAG 1.0.

Checkpoint 1.1 of the 26 January 2001 Guidelines [3] states:

   "Ensure that the user can operate the user agent fully through
   keyboard input alone, pointing device input alone, and voice
   input alone. [Priority 1]"

I propose splitting this checkpoint in three (rough wording

  Checkpoint A: "Ensure that the user can operate the user agent's
  native functionalities through keyboard input alone, pointing
  device input alone, and voice input alone. [Priority 1]"

  Checkpoint B: "Ensure that the user can operate
  device-independent functionalities specified in content through
  keyboard input alone, pointing device input alone, and voice
  input alone. [Priority 1]"

  Checkpoint C: "Allow configuration so that the user can operate
  device-dependent functionalities specified in content through
  other devices (e.g., simulate pointing device specific behavior
  through the keyboard). In this configuration, alert the user when
  an active element has device-specific behaviors associated.
  [Priority 3]"

I think that checkpoint C should be Priority 3 because it is
likely to provide incomplete repair. Thus, it clearly does not
qualify for P1 by definition:

   "This checkpoint must be satisfied by user agents, otherwise
   one or more groups of users with disabilities will find it
   impossible to access the Web."

There is no guarantee that if satisfied, checkpoint C will make
access possible. [I would also note that our priority statements
don't say anything about the responsibilities of other
parties. This is clearly an authoring issue first.]

Consider these scenarios:

1) The author has created content that is device independent. In
this case, checkpoint B applies.

2) The author has created content that is device-dependent, but 
has also provided alternative content (per WCAG 1.0 checkpoints
9.2 and 11.4). In this case, emulation is not required since the
author has ensured access.

3) The author has created content that is device-dependent, and
has not provided an alternative. The device-dependent content is

  a) Content that doesn't really depend on a particular device
     but has just been encoded that way, or

  b) Content that really does depend on a particular device
     (e.g., a user interface where the user scratches the 
     "silver paint" on an electronic lottery ticket to 
      reveal a hidden number).

The user agent can't recognize the difference in general, since
handlers are built with scripts. So that means that, in general,
the user agent is not likely to repair any better content of type
(3a) over content of type (3b).

Repair in case (3a) is probably useful to some users, can be
carried out automatically, and is technically feasible (e.g., the
UA could throw an "onmouseover" event whenever an "onfocus" event
occurs, or implement a "zap-mouse-to-focus" functionality).

However, in case (3b), emulation is not likely to help some
users.  Even a tool such as MouseKeys will not help some users
(e.g., users who are blind) interact with the user interface. If
the author has designed content that expressly takes advantage of
the nature of two-dimensional visual space, there's not much
users who are blind can do with certainty. Worse, emulating mouse
events might cause unexpected behavior to occur, thus
disorienting the user.  And, emulation of certain pointing device
events is less obvious (e.g., how do you translate "onmousemove"
to the keyboard?), so repair by the UA would likely be incomplete
on this axis as well.

In our current definition of "active element", we don't expect
the user agent to recognize (and thus repair) the class of
author-specified behaviors that are encoded through "event
bubbling" techniques.

Finally, the user agent should not be required to emulate
mouse-specific behaviors that are not controlled by the user
agent (e.g., the case of server-side image maps).


- Emulation of author-supplied device-specific behaviors seems to
be useful for some cases, and not helpful (or even disorienting)
in others. 

- The user agent is not expected to recognize the useful cases
from the non-useful cases since behaviors are encoded through
scripts today. This means that the user agent couldn't "warn" the
user, for example.

- Repair functionalities are likely to be incomplete and not
guarantee access, so I think that they should be Priority 3.

 - Ian


[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0227.html
[2] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#443
[3] http://www.w3.org/WAI/UA/WD-UAAG10-20010126/

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Wednesday, 21 February 2001 13:40:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:29 UTC