RE: issues with global attribute "accesskey" as-is in HTML5

> should the filing of a bug that accords with 
>
>http://www.w3.org/WAI/PF/HTML/wiki/Process_to_submit_HTML_spec_bugs

>
> wait (a discrete amount of time) for further discussion on-list 
> before they are filed as bugs?  

I will leave it up to the TF to decide what the delay if any should be in this case.  

But in general I personally believe that there is a low cost and high value to filing Bugzilla bugs since that documents the problem even if no changes are required to the specification.

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: Gregory J. Rosmaita [mailto:oedipus@hicom.net] 
Sent: Friday, July 23, 2010 1:15 PM
To: Paul Cotton; Janina Sajka; Michael(tm) Smith
Cc: public-html-a11y@w3.org
Subject: RE: issues with global attribute "accesskey" as-is in HTML5

aloha, paul!

i agree that they should be logged as bugs against HTML5, but was hoping
to get the TF to review them before filing them, as well as to ascertain 
if anyone on the TF has additional issues with @accesskey which also need 
to be logged as bugs -- should the filing of a bug that accords with 

http://www.w3.org/WAI/PF/HTML/wiki/Process_to_submit_HTML_spec_bugs


wait (a discrete amount of time) for further discussion on-list 
before they are filed as bugs?  thanks, gregory.
----------------------------------------------------------------
CONSERVATIVE, n.  A statesman who is enamored of existing evils,
as distinguished from the Liberal, who wishes to replace them 
with others.         -- Ambrose Bierce, _The Devil's Dictionary_
----------------------------------------------------------------
             Gregory J. Rosmaita, oedipus@hicom.net
  Camera Obscura: http://www.hicom.net/~oedipus/index.html

----------------------------------------------------------------

---------- Original Message -----------
From: Paul Cotton <Paul.Cotton@microsoft.com>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>, Janina Sajka
<janina@rednote.net>, "Michael(tm) Smith" <mike@w3.org>
Cc: "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Sent: Fri, 23 Jul 2010 13:03:01 +0000
Subject: RE: issues with global attribute "accesskey" as-is in HTML5

> Should these issues be raised as Bugzilla bugs on the HTML5 spec?
> 
> /paulc
> 
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
> 
> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-
> request@w3.org] On Behalf Of Gregory J. Rosmaita
 Sent: Thursday,
>  July 22, 2010 9:35 AM
 To: public-html-a11y@w3.org
 Subject: 
> issues with global attribute "accesskey" as-is in HTML5
> 
> aloha!
> 
> what follows is a list of issues with the accesskey attribute as
> defined in the current editor's draft of HTML5
> 
> when the HTML5 draft was submitted to the W3C by the WHAT WG,
>  the
 accesskey attribute had been removed;
> 
> http://www.w3.org/html/wg/wiki/DroppedAttributeAccesskey

> 
> the accesskey attribute was, however, subsequently re-added to 
> HTML5,
 so this post is a discussion of the global attribute 
> "accesskey" as it
 currently appears in the HTML5 draft:
> 
> http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute

> 
> ISSUE 1. is accesskey irretrievably broken as an attribute?
> 
> is an attribute (@accesskey) sufficient to provide the needed
> functionality or should the element approach outlined in the 
> Access
 Module/Element (which has the advantage of having been 
> vetted and
 modified due to feedback provided by the WAI, UAAG 
> and SVG WGs) be
 championed by the A11y TF?
> 
> further discussion at:
> * http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements

> 
> ISSUE 2. Valid Accesskey Values
> 
> in reference to accesskey values, the current draft of HTML5 
> states:
> 
> QUOTE
> value must be an ordered set of unique space-separated tokens, 
> each of
 which must be exactly one Unicode code point in length.
>  UNQUOTE
> 
> PROBLEM 2.1. accesskeys MUST be drawn from the charset used to 
> render
 the natural language of the document in which they 
> appear; an accesskey
 MUST be defined as a single character one 
> Unicode code point in length
 from the document character set.
> 
> ISSUE 3. Psuedo-Cascade of Multiple Accesskeys Definable for an 
> Individual
        Element
> 
> one can provide a "cascade" of accesskeys for an individual 
> element
 using a space delimited list; to take the example 
> currently in the HTML5
 draft:
> 
> QUOTE src-"http://dev.w3.org/html5/spec/editing.html#the-

> accesskey-attribute"
> 
> ... the search field is given two possible access keys, "s" and 
> "0" (in
 that order). A user agent on a device with a full 
> keyboard might pick
 Ctrl+Alt+S as the shortcut key, while a 
> user agent on a small device
 with just a numeric keypad might 
> pick just the plain unadorned key 0:
> 
> <form action="/search">
> <label>Search: <input type="search" name="q" accesskey="s 
> 0"></label>
 <input type="submit">
 </form>
 UNQUOTE
> 
> PROBLEM 3.1. cascade order is a very "weak" rather than a strong 
> binding
 -- how does the user know what accesskey to use when 
> multiple accesskeys
 are assigned to an individual element?
> 
> PROBLEM 3.2. "limited group of characters" -- there are a very 
> finite
 number of characters that one can use as an accesskey; 
> is the cascade of
 keys set using a space delimited list global? 
>  (that is, does every first
 item listed belong to accesskey-
> scheme A, the second to
 accesskey-scheme-B, etc.
> 
> <form action="/search">
> <label>Search: <input type="search" name="q" accesskey="s 
> 0"></label>
 <input type="submit" accesskey="= 1">
 </form>
> 
> in the preceding code sample, is the first accesskey theme:
> 
>  1. accesskey for input type="search" = s
>  2. accesskey for input type="submit" = =
> 
> (for fellow speech users, the first acesskey is the character s 
> while
 the second is the equals-sign)
> 
> and the second:
> 
>  A. accesskey for input type="search" = 0
>  B. accesskey for input type="submit" = 1
> 
> (for fellow speech users, the first acesskey is the character 0 
> while
 the second is the character 1)
> 
> if so, this needs to be explicitly stated in the HTML5 spec.
> 
> ISSUE 4. HTML5 hard-binds "Action" to accesskey key-press:
> 
> 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 4.1. this is at variance with the Access 
> Module/Element's
 architecture, which provides 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 4.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
> 
> REFERENCES:
> 
> Reference 1. PF's initial feedback to HTML WG July 2007:
> * http://lists.w3.org/Archives/Public/public-

> html/2007Jul/0903.html
> 
> QUOTE
> Outside of ARIA we would like HTML 5 to support the XHTML access
> element. The access element supports badly needed semantics for
> access key navigation but without the need for device dependency
> restrictions.
> UNQUOTE
> 
> for references to accesskey in WCAG 1.0 and 2.0, please consult:
> * http://www.w3.org/WAI/PF/HTML/wiki/Access#Accesskey

> 
> Reference 2. is accesskey irretreivably broken as an attribute?
> * http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements

> 
> Reference 3. accesskey in HTML5 (global attribute)
> * http://dev.w3.org/html5/spec/editing.html#the-accesskey-

> attribute
> 
> Reference 4. Last Public Draft of Access Module:
> * http://www.w3.org/TR/xhtml-access/

> 
> Reference 6. Last Editor's Draft of Access Module:
> * http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423

> 
> Reference 7. "The Access Element: Enabling Generic Document 
> Accessibility"
 [PFWG Proposed Internal Draft, 2010-05-19]
 *
 
> http://lists.w3.org/Archives/Public/www-archive/2010May/att-

> 0020/access-element-20100519.html
> 
> QUOTE
> source: http://lists.w3.org/Archives/Public/www-

> archive/2010May/0020.html
> 
> [The Access Element draft] is intended to provide a starting 
> point for
 work on the Access Element, based on the Last Call 
> Draft of the XHTML
 Access Module
> 
> http://www.w3.org/TR/2008/WD-xhtml-access-20080526

> 
> and the subsequent editor's draft which reflected refinements to 
> the
 Last Call draft due to feedback received during Last Call:
> 
> http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423

> 
> Although this document is a PROPOSED first editor's draft, it is 
> based on
 the Last Call Working Draft of the XHTML Access Module,
>  produced by the
 XHTML 2 Working Group. The XHTML Access Module 
> has been used as the basis
 of this document, as the XHTML 
> Access Module reflects a consensus among
 the members of the 
> XHTML2 Working Group, in conjunction with extensive
 input from 
> the User Agent Accessibility Guidelines Working Group and
 
> others in the accessibility and standards community.
> 
> Please note, as well, the new section entitled "Document 
> Formatting
 Conventions" which explains the formatting 
> conventions and mechanisms
 used so as to provide as much 
> information to the user so that an
 individual user can tweak 
> his or her technology to designate semantic
 markers, such as 
> "good examples" (green text on white background)
 and "bad 
> examples" (red text on white background)
> 
> Note that a rather vague attempt at replacing CURIEs (upon which 
> the
 XHTML Access Module had a dependency) with "named role 
> values"; this
 is a topic which needs to be discussed by the 
> PFWG (support for CURIEs
 now or in a future version, as was 
> done with support for CURIEs in the
 ARIA suite).
> 
> http://lists.w3.org/Archives/Public/www-archive/2010May/att-

> 0020/access-element-20100519.html
> 
> ----------------------------------------------------------
> He that will not apply new remedies must expect new evils;
> for time is the great innovator.      -- Sir Francis Bacon
> ----------------------------------------------------------
>            Gregory J. Rosmaita: oedipus@hicom.net
>        Camera Obscura: http://www.hicom.net/~oedipus/

------- End of Original Message -------

Received on Monday, 26 July 2010 14:55:43 UTC