Re: Keyboard support of mouse events for UAAG

At 01:51 PM 2001-02-09 -0600, Jon Gunderson wrote:
[ this message to the CG and a very similar message to PF.  I am responding to
all recipients of both transmissions, ]

>Chairs,
>The User Agent working group has had a long standing requirement for the 
>user to interact with active elements in a device independent way.  In 
>recent teleconferences we have been considering removing the requirement to 
>provide keyboard access to mouse based event handlers (onMouseOver, 
>onMouseOut, onClick) that are explicitly associated with an element as part 
>of the minimum requirement for conformance to UAAG.
>
>The reasons for reducing the requirement for active elements:
>1. We do not have any implementation experience for this feature.
>

AG::  As I understand it, there is a lot of experience with multiple
implementations of features which provide some capability to access mouse
events from the keyboard by driving the mouse cursor around the screen under
the control of key commands.  This is present both in screen readers and in
accessibility features of operating systems.

Perhaps a more careful statement of the predicament, here, is that there is
inadequate implementation experience with any solution that one would really
like as a full and final solution to this problem.

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

A rough estimate of the results of including the existing implementations is
that the P1 barrier is removed and a P2 barrier remains in its place.

So the solution that has lots of implementation experience is not everything
one would want. 

But it is not necessarily the best one can make of a bad situation to be
totally mute on a real problem just because we don't have the perfect solution
at a particular maturity level.

>3. This is a repair requirement for poor authoring and including the 
>requirement will continue to support poor authoring practices
>
>4. In general other repair requirements are a lower priority in UAAG

I think we need to be clear as to what is meant by 'repair,' here.  Sometimes
we use 'repair' to refer to functions which recover from content which
violates
the format specification.  That is not what we are discussing here.  Here we
are discussing a problem that would be no problem if all pages satisfied WCAG
1.0, Checkpoint 6.3.  The content being repaired is imperfect in its
conformance to W3C accessibility guidelines, not illegal with regard to the
format specification.  This is a policy issue where it is probably good that
the Coordination Group give this issue some thought.  What we are dealing with
is a reasonably widespread situation which violates the W3C Recommendation for
Web Content Accessibility.  What sort of a position should we be asking the
W3C
to take as regards redundant measures to address this problem via User Agent
functionality as well as content guidelines?  I have frequently argued that
_some_ redundancy as regards content guidelines and browser guidelines is
probably indicated.  But that still leaves open the question as to how much
redundancy, and what to do in this case.

In particular, the Protocols and Formats Working Group is sorry that we have
not been able to purge the formats of device-specific events yet.  If the User
Agents take on this functionality, it is in part because of our failure to
repair the fabric of format specifications any faster.  That's not ideal, but
it is real.  The events as defined in the formats today are device-specific,
and in widespread use across the Web, with many pages failing WCAG 1.0,
Checkpoint 6.3 in one way or another.

The direction that we are trying to take with the formats is to get them to
derive all user interface events from device-independent abstract event
classes.  But the User Agent would in this case still be responsible for
providing device-independent ability to create these abstract events.  The
Checkpoint 6.3 approach is not something I really expect to take root and
persist into the indefinite future.  So it is not that likely that this
function, if implemented now in User Agents, would be soon overtaken by better
solutions from other sources (content compliance or format evolution).

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

I am not going to comment on this prognosis at this point, as it would seem
there is more implementation experience than you were giving yourselves credit
for, and the repair functionality policy question has not been resolved.

>The reasons to maintain requirement:
>1. It is an important accessibility problem and that User Agent needs to 
>require the repair
>
>My question to the coordination group is do you agree with the reasons for 
>reducing the requirement to eliminate support for pointer based events as 
>part of the minimum requirement for conformance, or do you think that this 
>is such an important problem that we should include, even though we do not 
>have any implementation experience?

It's a knotty problem.  I would prefer not to make a bottom line
recommendation
until I have heard more perspectives on the repair policy question.

Al

>
>Thanks,
>Jon
>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>http://www.staff.uiuc.edu/~jongund
>WWW: <http://www.w3.org/wai/ua>http://www.w3.org/wai/ua
>

Received on Sunday, 11 February 2001 20:35:00 UTC