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

Re: Repair of Pointer Based Events

From: Charles McCathieNevile <charles@w3.org>
Date: Fri, 9 Feb 2001 16:46:41 -0500 (EST)
To: Jon Gunderson <jongund@uiuc.edu>
cc: WAI PF group <w3c-wai-pf@w3.org>, WAI UA group <w3c-wai-ua@w3.org>
Message-ID: <Pine.LNX.4.30.0102091638220.20759-100000@tux.w3.org>
I can't speak for PF, but personally I very strongly disagree with the
reasons for reducing the priority or removing the requirement. Further
comments below.

On Fri, 9 Feb 2001, Jon Gunderson wrote:
  The reasons for reducing the requirement for active elements:
  1. We do not have any implementation experience for this feature.

MouseKeys implements this feature. The only bit it does not commonly provide
is the abilitry  to move the mouse cursor to a point that has been reached by
keyboard navigation (which isn't explicitly required by the feature - it is
just a technique that leverages the fact that mousekeys is readily available
on common platforms such as linux, MacOS, Windows)

  2. Without implementation experience we do not know how the inclusion of
  the feature will affect accessibility

People should be able to tell us the problems associated with not having
mousekeys in general. I have seena specific example in using a software
application, where a user was required to position a mouse cursor, and fire a
click event. Being blind, this was accomplished by making a known number of
moves with a keyboard emulation, which was also used to provide the click.

  3. This is a repair requirement for poor authoring practices and including
  the requirement will continue to support poor authoring practices

True, but only in the sense that including the requirement means that users
can get acess to content even if authors are bad at what they do. It seems
likely that some authors will always use poor practices, so some users will
always need to be able to make use of repair functions. And good authoring
practices are in this context close to being just another repair function.

  4. In general other repair requirements are a lower priority in UAAG

But the priority scheme is based on user impact, not on what priority other
features have that might be similar in some way.

  5. Without implementation experience we may need to go to Candidate
  Recommendation until implementation shows a P1 benefit, delaying
  publication of current requirements.

The alternative would be to go through without the requirement. It would then
not be a requirement until a new version of the document is produced. This is
likely to be at least a couple of years, is it not?


Received on Friday, 9 February 2001 16:46:43 UTC

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