- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 3 Jun 2005 12:46:56 -0400
- To: "John Foliot - WATS.ca" <foliot@wats.ca>, <www-html@w3.org>
- Cc: <w3c-wai-ig@w3.org>
Thank you for this beautifully-wrought argument. Much of this I agree with. Let me expand on a few points of divergence. ** summary Yes, 'author proposes' is required for hotkey bindings. This is needed both for application-specific hotkeys and for getting the authors to identify the hotspots whose access should be accelerated. Yes, an element is needed because what is needed is a menu entry and that needs to be internationalized, including essential markup such as <ruby>. This is not to say we shouldn't be accelerating items based on their roles. Quite to the contrary. Review the Table of Contents function in the Mozilla Access Extension being developed in conjunction with the 'role' work. http://lists.w3.org/Archives/Public/wai-xtech/2005May/0011.html And I suspect once we have it right, the default ToC will pick up headers automatically without having to add 'role' qualification to them. But the author-extension option needs to be there, duly integrated into the event model. Given the fact that SVG 1.2 Tiny is ahead of XHTML 2.0, we may be able to lose the 'access' attribute and element entirely in favor of an sXBL application before this format is done. ** details inline below At 5:06 PM -0400 6/2/05, John Foliot - WATS.ca wrote: >Al Gilman wrote: >> >> But at a simpler level, the framework for Multi-modal interaction >> will cover, hopefully, the needs of handling alternate >> modes of input as configuration options. The latter case is what >> we are trying to institutionalize in replacement for ACCESSKEY. > >By creating an element known as "access" and giving it a possible attribute >of "key"? You have got to be kidding. >(http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule) No, that would not be my first choice. but it is a feasible syntax so long as the client-side management and overriding of the UI-event bindings is duly specified and implemented. http://lists.w3.org/Archives/Public/www-html/2004Aug/0032 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 If that functionality has been broken in this draft, we need to fix it. In my theoretical model, the 'access' element is specifying a pseudonym for the event DOMfocusIn(here) or in other uses a pseudonym for DOMactivate(here). This is a binding that belongs in the 'views' layer of the DOM. And since half the accesskeys are actually intended as pseudonyms for firing DOMactivate(here) there is not point for a half-replacement with a dedicated element that only generates the focus behavior. What we need to get across is that we are really annotating an event with a [menu entry and] hotkey. Not an element. And since the 'focusIn' and 'activate' events are already well defined, we don't need any new constructs to create them. > > However, we want to preserve the *author's* access to binding > > the events in a provisional way, so that they can create their >> own look-and-feel and not be totally dependent on published > > conventions. > >This is, frankly, poppycock. The real question is *why*? By preserving >this capacity for explicit binding you perpetuate the basic problem that >exists with the current accesskey - lack of standardized keys, pre-claimed >and conflicting key bindings for various user-agents and adaptive >technology, etc., etc. There are two 'why' answers that to me validate the requirement for an "author proposes" part to this "author proposes, user disposes" key binding. - one is application-specific verbs. My posterkids for these are some of the actions in a web-ified email archive or WebMail ap. These would include "next message in thread" or "this message in threaded index view." Waiting for standard terms for these is a losing play. Standard terms in new application domains (such as 'home' in the Web) will emerge, but predicating - the other is author interest. If the author is not given the opportunity to create a complete user experience, they won't create the semantic underpinnings, either. If we let authors nominate hotkeys, they will identify the top hot-key-able targets in the page. Else, not. We need them identified; we need the carrot to bring the authors to the table. I believe that asking authors to create intent-based events without affording them the means to nominate UI event triggers for them will create a feature gathering dust on the shelf like the 'link' element in HTML. So, there is sufficient reason to let the author propose something. The flip side is also true: removing the author's ability to nominate keys will not achieve the standard UI names that you would prefer. That is a topic of balance-of-terror detente among the OS vendors. JTC1 SC35 is trying to do that and like ISO HTML, it will be roundly ignored in the real world. The place where we can have a reasonable expectation of uptake in the commercial Web is at one remove from the user experience, in naming the intent-based events. >I like "Role", I like the pre-determined list of common roles and the fact >that role is extensible via RDF. Leave it there. Let the users determine >the how and what. Never mind letting the author "guess" which key is most >appropriate. I honestly thought that we had gotten past "look" as a >criteria, leaving that to CSS. CSS needs semantic info in the 'content rep' to key when to do what. If the hotkey is specified in a CSS rule with a #id selector, then the CSS is not style, it is holding content hidden from the AT cruising the DOM through the access API. You're lost in some theoretical world if you don't admit that web developers *must* optimize the look and feel of their web aps to stay in business. We *must* preserve the adjustability of that look and feel. But we will simply fail if we try to do anything less than facilitating that optimization by the content developers. >(Besides, doesn't the RDF extensibility of >Role extend it beyond the "common conventions"?) > >> [The balance here is a matter of contention in the >> community. But the current thinking in PF is that the author >> proposes UI bindings, and the User and User Agent may override >> these where the user asserts a clear preference.] >> http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html > > >If the WG feels Sir, you're dealing with two working groups, here. The latest draft XHTML 2.0 has been developed by the HTML WG. The idea that the XForms language is "good enough" in terms of assuring access is a matter that was consensus in the PF WG the last time it came up for consensus. The current draft was supposed to be a Last Call draft, that the HTML WG considered 'done.' It is not. Not even the HTML WG thinks that they have got every detail right in this draft. So bear with us, it is a work in progress. >that having the "key" attribute is important, why are you >deprecating accesskey? What, honestly and truthfully is the difference >between: > > access key="S" and accesskey="S" > >...outside of the fact that one is an attribute, the other an element? Both >bind that particular "thing" to "S", whether or not "S" is already claimed >by something else on my configuration or not. It does not solve many of the >inherent problems currently experienced with accesskey. So why bother? > >To further state that user agents and/or end users should then somehow be >allowed to explicitly over-ride the author's binding... C'mon... Is the only way to strike a deal between author and user interest that will fly in the massively distributed-authoring flow of information on the Web. >How did all of this: > ><q>The user has better knowledge of what works for them and what does not >than an author trying to prepare an experience for multiple users. > >{plus} > >Users quite generally prefer not to change the author's presentation or >UI design, and to change it as little as possible where necessary. Most of >the people using something other than the default presentation or input >binding the author offered are people who need to use something different. > >{and finally} > >When there are many settings associated with adapting a user interface, >the user may not be able to navigate the interface state to an optimum.</q> >(http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html) > >...end up like this: > >(The Draft states:) "Note. Authors should consider the input method of the >expected reader when specifying an accesskey." Plus the brilliant: "User >agents should render the value of an access key in such a way as to >emphasize its role and to distinguish it from other characters (e.g., by >underlining it)." [Let's be sure to let all our blind friends over at WAI >know to watch out for an underlined letter, OK?] >(http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule) > >That's a lot to put on the end user, all for the benefit of some >Photoshop/Dreamweaver jockeys who want to preserve their "look and feel"... > >We've already seen, first hand, what happens when well meaning but poorly >informed authors impose what they think is best; You get entities such as >the UK government *mandating* an accesskey of "S" to be bound to "search", >despite the fact that a tool like IBM HPR uses the same keystroke (ALT+S) to >get to user settings! (http://wats.ca/resources/accesskeysandkeystrokes/38) >Why even give them the opportunity to mess things up? > >How did this come to pass? In Draft 20040722 (http://tinyurl.com/797na) you >guys had it right, one draft later it's gone to being yet another useless >oddity ripe for abuse. > >THIS IS JUST PLAIN WRONG! Thank you for your persistence in trying to keep us honest. Al > >JF >-- >John Foliot foliot@wats.ca >Web Accessibility Specialist / Co-founder of WATS.ca >Web Accessibility Testing and Services >http://www.wats.ca >Phone: 1-613-482-7053
Received on Friday, 3 June 2005 16:47:12 UTC