[Bug 10905] clarify how assigning an accesskey to an element affects the elements default role

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10905

--- Comment #5 from steve faulkner <faulkner.steve@gmail.com> 2010-10-14 08:57:06 UTC ---
(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?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 14 October 2010 08:57:09 UTC