Edit comment LC-2810 for Accessibility Guidelines Working Group

Previous: LC-2826 Next: LC-2809

Comment LC-2810: Comment Shortname:; Commenter: harry.loots@ieee.org; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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.; Related issues: (space separated ids); WG Notes:; Resolution: 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.; (Please make sure the resolution is adapted for public consumption)