This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When an onclick attribute is added to any element that cannot receive focus the interaction is not accessible and should trigger a conformance error. it also overloads the default semantic of the element. furthermore a corresponding onkeypress is required to make it operable usable with the keyboard, so suggest conformance advice in this regard. example: <h1 onclick="copy()">copy</h1>
No. This ignores the possibility of there being alternative techniques provided within the page that perform an equivalent action. There is no programmatic way to determine if any given action is inaccessible by the presence of an event handler attribute, and a validator should thus not be used to try and enforce such accessibility guidelines. Also, authors who cared about validity would simply workaround the error by attaching the event listener another way that is impossible for the validator to detect.
(In reply to comment #1) > No. This ignores the possibility of there being alternative techniques provided > within the page that perform an equivalent action. There is no programmatic > way to determine if any given action is inaccessible by the presence of an > event handler attribute, and a validator should thus not be used to try and > enforce such accessibility guidelines. Your response does not resolve the issue of onclick overloading the semantics of any given element. > Also, authors who cared about validity would simply workaround the error by > attaching the event listener another way that is impossible for the validator > to detect. Exactly the same can be said for the use of the role attribute on an element.
(In reply to comment #2) > Your response does not resolve the issue of onclick overloading the semantics > of any given element. onclick doesn't overload the semantics of any element. It just adds an event listener to it.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I don't understand. Could you elaborate? What is "conformance advice"?
http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html The bug triage sub-team thinks the HTML A11Y TF does not need to formally follow this bug. Original submitters or other interested parties may choose to continue to push this issue on their own. Notes from the sub-team may follow in a separate comment.
Bug triage sub-team says not high enough priority for TF, though Steve may continue to push on it; there's a wider design issue involved, not useful to require fine-grained warnings.
Closed per http://lists.w3.org/Archives/Public/public-html/2010Oct/0135.html