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

I think new Checkpoint C Ian has proposed as a general repair checkpoint 
for pointer device dependent event handlers is a good addition to the 
guidelines.  Checkpoint C probably rates a Priority 3 given the scope of 
repair that could potentially be done and our current lack implementation 
experience for the range of things that could be done and the knowledge on 
how different techniques improve access to content by people with 
disabilities.

But the group has decided to include in UAAG specific pointing based events 
to be simulated/activated through the keyboard as a priority 1 
requirement.  So I propose the following additional checkpoint at the 
Priority 1 level:

Checkpoint D: Provide keyboard activation of the following pointer based 
scripting events for elements with explicit event handlers: onClick, 
onDblClick, onMouseOver, onMouseOut, onMouseUp and onMouseDown [Priority 1].

Note: The event object generated for these events need to include pointer 
coordinates that are either inside or outside the element box (defined by 
CSS?) associated with the event depending on the intrinsic event type 
(coordinates inside the element box, accept for onMouseOut) and the 
specification of a right, left, middle or combination pointer button 
press.  The user agent is not required to generate a user specified set of 
pointer coordinates associated with onMouseUp and onMouseDown, or support 
user agent simulated pointer movement associated with onMouseMove (though 
it should still be compatible with built-in accessibility features like 
mousekeys).

This checkpoint is an important special case of the new Checkpoint C 
proposed by Ian.

Questions:
1. Do we want to include onMouseUp and onMouseDown?  Leaving them out 
reduces the requirement for specifying left, right, middle or combination 
pointer button presses.

2. Is this a sufficient enough requirement or do we need more or less?

Jon

At 08:59 PM 2/21/2001 -0500, Charles McCathieNevile wrote:
>No.
>
>It is not about guaranteeing access, it is about providing a way to alleviate
>a problem, which (at P1 level) is otherwise guaranteed to prevent access.
>
>I like thje way the proposal is worded, since it makes it clearer just what
>must be done in each situtation, but I disagree that it is a priority 3
>requirement.
>
>Charles McCN
>
>On Wed, 21 Feb 2001, Jon Gunderson wrote:
>
>   Ian,
>   I like the reasoning behind the proposal.  I agree that the repair we have
>   talked about has dubious guarantees of making content accessible.  What do
>   other people think of the proposal?
>
>   Jon
>
>
>   At 01:40 PM 2/21/2001 -0500, Ian Jacobs wrote:
>   >Hello,
>   >
>   >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
>   >here):
>   >
>   >   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
>   >either:
>   >
>   >   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).
>   >
>   >----------
>   >CONCLUSION
>   >----------
>   >
>   >- 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
>   >
>   >----------
>   >References
>   >----------
>   >
>   >[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
>
>   Jon Gunderson, Ph.D., ATP
>   Coordinator of Assistive Communication and Information Technology
>   Division of Rehabilitation - Education Services
>   MC-574
>   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
>
>
>
>--
>Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 
>134 136
>W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 
>258 5999
>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, 
>France)

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
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

Received on Wednesday, 21 February 2001 21:48:16 UTC