- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Sun, 5 Jun 2005 09:13:08 -0400
- To: <charles@sidar.org>, <wai-xtech@w3.org>
- Cc: <w3c-wai-ig@w3.org>, <www-html@w3.org>
Chaals wearing his SIDAR hat wrote: > [the Cc list is getting out of hand here...] Yes, sorry. My passion and enthusiasm got the better of me. > <snip> > > But in this case the author's suggestion has to be subject to > the browser, as well as to the user's demands. And given the infinite possible user-demand configurations, how can an author ever hope to understand and deliver to each scenario? > > The alternative to having the author pick keys is to have the browser > assign them according to some kind of algorithm. Nothing > stops the browser > doing this, so if it is useful you can expect good browsers > to offer the > possibility. For example if a role is a subtype of a known > role where a > user has expressed a preference. Or if a common set of > bindings for roles > in a given language are published, a user may prefer > everything relevant > be remapped to those bindings. (These two example can, of course, be > combined). Yes, and I have said as much. The current Draft has already enunciated a set of "standard" role values (and perhaps we need to look more closely at these to ensure that nothing important has been missed), so user-agents could indeed do mappings (or expose themselves in other ways - see the Web Accessibility Extension from Jon Gunderson) based upon these roles. No need for authors to assign keystroke combinations if the roles they seek are from the standard list - in fact this puts the 'standardization' role into the hands of one body, the W3C, as opposed to many - this has to be a good thing. As a working author, if I know that the role of "navigation" (with keystroke mapping 'automatically applied' for all) could be gained simply by my adding the role attribute to the appropriate element, this makes my life easier. This would lead to better author adoption. I don't have to guess which one is right, or seek out (conflicting) standards/guidelines. > > But if someone comes up with something that is apparently > entirely new, > what is the best shortcut? <snip> > > It seems to me useful to *allow* the author to *suggest* a default > binding. Users don't want to have to suggest it until they > actually need to > use it and decide that it doesn't make sense so they should re-map it. Chaals, this statement ("Users don't want to...") is based upon what? Research or gut feel? I often trust both, but in the context of this discussion I think that the answer may be important. > Computers are not that good at user interface design. Which > leaves me with > the content author as the best person to give an *initial suggestion*. But if this is the case, what about conflict resolution? Who decides, what is the precedence, and how is it invoked? I have not seen this addressed elsewhere, and these points are crucial to the total picture. Without this firm guidance (standard?), my fear is that the access element will become the same mess that accesskey evolved to. If it is not already clear to everyone, I am advocating FOR good keyboard navigation. I believe it to be useful and important. My concerns are not about the whys, but rather the hows. My perspective is based from that of the end user, who experience has taught us, is less than likely to fiddle with their user-agent settings - they will just 'suffer' through something that is broken for fear of further breaking things. Thus the undo-redo option, to me, is the less preferable one, where-as auto-discovery and option "to enhance" is the better route. To *my* gut feeling, better for a browser/user-agent to "auto-discover" new access (points? Roles? Declarations?) and allow the user to map first, rather than have to discover, undo and redo the author's idea. To me, this is the path of least resistance and greatest ease of use, but this is based upon my *gut*, and without the benefit of research. It also however addresses keyboard internationalization, something that has possibly been overlooked. Witness the Opera browser, and its "Mouse Gestures". The first time you "do" a mouse gesture in Opera, a dialogue box opens (auto-discovery) and tells you that you can invoke this option. You don't have to, but you can. This puts the end user in the control seat. Imagine instead, if the first time invoked the Mouse Gesture instead "did" something un-expected... The end user would then have to find out what happened, find out how to undo it (if they chose), etc., etc. How (in the big picture) is this any different than author defined access keys? Why does the author, and not the end user, get to have the first say? 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 Sunday, 5 June 2005 13:13:24 UTC