[Bug 10252] New: HTML5 hard-binds "Action" to accesskey key-press

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

           Summary: HTML5 hard-binds "Action" to accesskey key-press
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://dev.w3.org/html5/spec/commands.html#command-fac
                    et-action
        OS/Version: All
            Status: NEW
          Keywords: a11y
          Severity: blocker
          Priority: P1
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: oedipus@hicom.net
         QAContact: public-html-bugzilla@w3.org
                CC: oedipus@hicom.net, mike@w3.org, public-html@w3.org,
                    public-html-a11y@w3.org


QUOTE
   src="http://dev.w3.org/html5/spec/commands.html#command-facet-action"
When the user presses the key combination corresponding to the assigned 
access key for an element, if the element defines a command, and the 
command's Hidden State facet is false (visible), and the command's 
Disabled State facet is also false (enabled), then the user agent must 
trigger the Action of the command.
UNQUOTE

PROBLEM 1. this is at variance with the User Agent Accessibility 
Guidelines -- the solution provided by the Access Module/Element's 
architecture, is a boolean attribute "activate" which allows 
an author to set the AccessKeyPress to either move focus to the object 
for which the accesskey is defined (activate="no") or whether the 
AccessKeyPress results in the activation of the element to which the 
accesskey has been assigned (activate="yes")

PROBLEM 2. the Access Module/Element's "activate" attribute also 
provides the following, which is lacking in the HTML5 draft:

QUOTE src="http://www.w3.org/TR/xhtml-access/#sec_3.1.1."
User agents MUST provide mechanisms for overriding the author setting 
with user-specified settings in order to ensure that the act of moving
content focus does not cause the user agent to take any further action 
(as per Checkpoint 9.5 of UAAG 1.0)
UNQUOTE

REQUIREMENT: the user MUST be able to toggle between accesskey moves 
focus to associated element, or to have that element activated, in 
accordance with a user setting;

NOTE: this implies strongly that focus/activate SHOULD: a) provide a 
toggle as to default action; b) provide an extra modifier (for example, 
ModifierKey1+Accesskey to focus and ModifierKey2+Accesskey to activate, 
or ModifierKey1+Accesskey to focus and ModifierKey2+ModifierKey1+Accesskey 
to activate;

-- 
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 Wednesday, 28 July 2010 21:05:35 UTC