W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2005

what sort of precedent? [was: Re: Access Element is WRONG ...]

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Fri, 3 Jun 2005 16:17:59 -0400
Message-Id: <p0611040abec666ebca61@[]>
To: Micah Dubinko <micah@dubinko.info>
Cc: "John Foliot - WATS.ca" <foliot@wats.ca>, www-html@w3.org, w3c-wai-ig@w3.org

At 11:17 AM -0700 6/3/05, Micah Dubinko wrote:
>For the record, XForms' treatment of accesskey should not be viewed 
>as any kind of a precedent.

Let me clarify what sort of a precedent I meant.

I agree that the XForms specification does not (and should not)
require host languages to implement the 'accesskey' feature as
described or any other specific implementation of the required

On the other hand, the PF WG requested from the Forms WG that a
proviso be added to the description of ACCESSKEY specifically
mentioning the need to afford the user review and configuration of
key bindings, if key-bindings were to be indicated by the author.

Yes, the definition was 'roughly' taken from prior format
specifications, but the _refinement_ to make explicit mention of this
user capability was no accident, no 'roughness' in the heredity from
those specifications. It was the results of comparison with the UAAG
and discussion between the WAI and the WG producing the spec.

So it sets a precedent to the extent that one should reasonably expect
the WAI, presented with another format implementing an accesskey-like
function, to demand that the user ability to review and re-bind to alternate
input events be part of the specification.

I would have had a precedent to cite in normative text but for an
editorial error in the production of the SMIL 2.0. But a miss is as
good as a mile when I need a publicly accessible reference.

I hope this clarification meets your approval.


>The normative part states "a host language must provide a way to 
>indicate overall navigation order among form controls and other 
>elements included in the host language, as well as keyboard or 
>direct access navigation to specific elements. One such proposal is 
>to uses a pair of attributes named |navindex| and |accesskey|, 
>defined as follows:"
>The actual definitions are taken roughly from older specifications. 
>My understanding is that things were specified this way specifically 
>because of the inadequacy of navindex/accesskey, and to not forclose 
>the development of better techniques in host languages.
>No comments on the rest of the message. Thanks,
>Al Gilman wrote:
>>The precedent is set in the XForms specification.
>>Optional attribute defines a shortcut for moving the input focus
>>directly to a particular form control . The value of this is a
>>single character which when pressed together with a platform specific
>>modifier key (e.g., the alt key) results in the focus being set
>>to this form control .
>>The user agent must provide a means of identifying the accesskeys
>>that can be used in a presentation. This may be accomplished in
>>different ways by different implementations, for example through
>>direct interaction with the application or via the user's
>>guide. The accesskey requested by the author might not be made
>>available by the player (for example it may not exist on the
>>device used, or it may be used by the player itself). Therefore
>>the user agent should make the specified key available, but may
>>map the accesskey to a different interaction behavior.
>>found by string searching 'accesskey' in:
>  Available for consulting. XForms, web forms, information overload.
>  Micah Dubinko                           mailto:micah@dubinko.info
>  Brain Attic, L.L.C.                        http://brainattic.info
>  Yahoo IM: mdubinko                                +1 623 298 5172
>  Learn XForms today: http://xformsinstitute.com
Received on Friday, 3 June 2005 20:18:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:32 UTC