- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 3 Jun 2005 16:17:59 -0400
- 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 capability. 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. Al >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, > >.micah > >Al Gilman wrote: > >> >>The precedent is set in the XForms specification. >> >><quote> >> >>accesskey >> >>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. >> >></quote> >> >>found by string searching 'accesskey' in: >>http://www.w3.org/TR/xforms/index-all.html > >... > >-- > 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:31:00 UTC