W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > September 2013

Re: Poor example ( LC-2810)

From: <akirkpat@adobe.com>
Date: Sun, 22 Sep 2013 14:46:17 +0000
Message-Id: <E1VNkvR-0002Mq-Jw@jessica.w3.org>
To: harry.loots@ieee.org
Cc: public-comments-wcag20@w3.org
 Dear harry.loots@ieee.org,

The Web Content Accessibility Guidelines Working Group has reviewed the
comments you sent [1] on the Last Call Working Draft [2] of the Techniques
for WCAG 2.0 published on 11 Jul 2013. Thank you for having taken the time
to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-comments-wcag20@w3.org if you agree with it or not before 2 Oct
2013. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Web Content Accessibility Guidelines Working Group,
Michael Cooper
W3C Staff Contact

 1. http://www.w3.org/mid/E1V9BFc-0002YF-4L@crusher.w3.org
 2. http://www.w3.org/WAI/GL/2013/WD-WCAG20-TECHS-20130711/


=====

Your comment on SCR20: Using both keyboard and other device-specific
functions:
> Name: Harry Loots
> Email: harry.loots@ieee.org
> Affiliation: EPO
> Document: TD
> Item Number: SCR20
> Part of Item: Examples
> Comment Type: technical
> Summary of Issue: Poor example
> Comment (Including rationale for any proposed change):
> Using onkeypress with onclick is redundant. Additionaly onkeypress has
> to be specifically scripted to ensure that the Enter key has been
> pressed, otherwise any keypress will activate it. 
> 
> Proposed Change:
> Suggest:
> 
> 1) that specific advice be provided that onclick should be used on its
> own (i.e., without keyboard equivalent) for the reasons stated above. 
> 
> 2) the onmousdown/onkeydown would be a better example, should a second
> example.


Working Group Resolution (LC-2810):
Thank you for your comment.  

According to our testing, onkeypress is not redundant to onclick for
non-native HTML controls, that is, for HTML elements that are not natively
focusable.  If a developer makes an image clickable with onclick that item
does not respond to keyboard events unless onkeypress is provided.  

It is accurate that the author does need to control the script so that the
appropriate keypress is accepted and other keypresses are ignored, but this
is detailed in the example's description.  

We would welcome an onmousedown/onkeydown example if you or others wish to
provide one to be added to this technique.

The description of the technique does not currently draw the distinction
between native and non-native HTML controls, which is confusing. We have
updated the technique to make this clearer:

[DONE] Change Note 1 to: "Although click is in principle a mouse event
handler, most HTML and XHTML user agents also process this event when a
native HTML control (e.g. a button or a link) is activated, regardless of
whether it was activated with the mouse or the keyboard. In practice,
therefore, it is not necessary to duplicate this event when adding handlers
to natively focusable HTML elements. However, it is necessary when adding
handlers to other events, such as in Example 2 below.



----
Received on Sunday, 22 September 2013 14:46:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:17 UTC