This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
in the editor states "for example any element with accesskey="" can end up having a role." http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603 yet it is not specified in the spec (that I can find) how the adding of an accesskey to "any element" affects its role for example how is the role of the following affected by the presence of an accesskey? <h1 accesskey="a">poot</h1> or <p accesskey="a">pooter</a> or <td accesskey="a">pootsville</a>
All three turn into role=menuitem. What is the request here? It's not clear to me what change is being requested or what problem needs solving.
(In reply to comment #1) > All three turn into role=menuitem. > What is the request here? It's not clear to me what change is being requested > or what problem needs solving. apologies for being unclear, the problem is that it is not clear to me what effect adding an accesskey attribute has on the default role of an element. Please add a clarification to the ARIA section of the spec stating that the default role of any element which has an accesskey attribute is overidden by role="menuitem" if this is the case. so what is the role of <h1 accesskey="a" role=button"> hello </h1> please add clarification in the spec for cases such as the above.
All the access key does is give an element focus unless it is a link and it would follow it. So, I am not following Ian's line of thought.
Setting the "accesskey" attribute results in the element having an "assigned access key". - http://c.whatwg.org/m#the-accesskey-attribute - http://c.whatwg.org/m##assigned-access-key An element that has an assigned access key defines a command. - http://c.whatwg.org/m#using-the-accesskey-attribute-to-define-a-command-on-other-elements An element that defines a command, whose Type facet is "command", and that is a descendant of a menu element whose type attribute in the list state has strong native semantics and implied ARIA semantics giving it a menuitem role. - http://c.whatwg.org/m#annotations-for-assistive-technology-products-(aria) So, if you have a page like this: <!DOCTYPE HTML> <title>Demo</title> <menu> <h1 accesskey="a">Demo</h1> </menu> ...then the <h1> element will have the role "menuitem". This seems pretty clear in the spec, and is a rather obscure edge case (and one that, at least for <h1>, is pretty useless and not especially interesting to authors), so I don't really see why an example would help here. Could you clarify whether you really want an example for this? It's not clear to me how authors would benefit from one.
(In reply to comment #4) > Setting the "accesskey" attribute results in the element having an "assigned > access key". > - http://c.whatwg.org/m#the-accesskey-attribute > - http://c.whatwg.org/m##assigned-access-key > > An element that has an assigned access key defines a command. > - > http://c.whatwg.org/m#using-the-accesskey-attribute-to-define-a-command-on-other-elements > > An element that defines a command, whose Type facet is "command", and that is a > descendant of a menu element whose type attribute in the list state has strong > native semantics and implied ARIA semantics giving it a menuitem role. > - http://c.whatwg.org/m#annotations-for-assistive-technology-products-(aria) > > So, if you have a page like this: > > <!DOCTYPE HTML> > <title>Demo</title> > <menu> > <h1 accesskey="a">Demo</h1> > </menu> > > ...then the <h1> element will have the role "menuitem". > > This seems pretty clear in the spec, and is a rather obscure edge case (and one > that, at least for <h1>, is pretty useless and not especially interesting to > authors), so I don't really see why an example would help here. > > Could you clarify whether you really want an example for this? It's not clear > to me how authors would benefit from one. So when its not inside a menu <!DOCTYPE HTML> > <title>Demo</title> > <h1 accesskey="a">Demo</h1> the role is?
"heading", with some aria-level value. Can I close this bug?
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: This bug does not seem to request a change to the spec.
Bug triage sub-team assigning to Gregory to track with keyboard access issues. Dependency on 10888 is is the keyboard access requirements.
a11ytf decision to move to HTML.next: http://www.w3.org/2013/10/17-html-a11y-minutes.html#item04 New bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23616
*** This bug has been marked as a duplicate of bug 23616 ***