there does remain an issue as to whether single letter strokes outside of a text box should refer to links or configuring? These are both important, and a browser developer could implement this, unfortunately the mozilla example I gave is a bug that 'works' even in a text box :-( but it would not be completely unreasonable to imagine that some letters (xzvy perhaps) might be best served for most users if they were reserved for some essential tasks back, shift already having been taken. Jonathan apologies if this has been discussed already. On Thursday, February 27, 2003, at 09:43 PM, Charles McCathieNevile wrote: Summary: + The functionality you propose can be readily implemented in browsers (and is, in mozilla). But I don't think that getting authors to do it is a good idea, and it doesn't actually replace accesskey. + There should only be a few accesskeys on a page, and consistency across sites is a good thing. Browsers may reassign keys, but authors should start with easily memorised ones that look like things they have seen elsewhere. + this has been discussed before in WAI - starting from http://lists.w3.org/Archives/Public/wai-xtech/2002Sep/0045 there was one response listed in our threading system (which breaks down if discussions go across months :( The discussion continued with most of the messages in http://lists.w3.org/Archives/Public/wai-xtech/2002Oct/thread and http://lists.w3.org/Archives/Public/wai-xtech/2002Nov/thread and finished with the message at http://lists.w3.org/Archives/Public/wai-xtech/2002Dec/0001 (Not the summary message, just the last) That discussion has talked about ways to find out what accesskeys are available. This mail only addresses one possible approach to that problem - there are others. Details: Accesskey is a way of providing a quick way to get to the handful of most important links or controls on a page, and I think that its value is increased when the same set of shortcuts can be used across a site or group of sites (as proposed by Nick, and in the earlier discussion for Canadian sites, and implemented on sites like http://www.ubaccess.com and others). The most efficient use of this, for people who have trouble with producing input (poor hand control, using a slow system like a switch/scanner or morse-code, etc) is to directly activate the control with the minimum work - like iCab and many mobile phones, which allow directly following a link by pressing just the relevant key itself. (Note that for phones this is generally limited to number keys). For some people it is too easy to get lost doing this, and they prefer a browser that takes a couple of cancelable steps before the control is activated - IE requires alt, an accesskey, and then pressing enter/return to activate a link. So far so good - you configure or choose your browser to have the most direct activation or the safe mode, and there are a few accesskeys on a page. What should the accesskeys be assigned to? The author of a page is likely to have an idea about what are the important controls (because they did market research and usability testing to find out, in an ideal world or where they care about their service and their users). They are also likely to have enough of an overview of the site to think about the collection of accesskeys that might be useful throughout the site (not all keys might be relevant to all pages). Obvious candidates are things that appear on most pages - search, the top of the page, a link to some start page or homepage, major parts of the site. Cool things, or popular things. Divisions in a page that are very common (the table of contents in W3C specifications, for example). Important configuration controls. The list can be long - think carefully and choose. (Then test with users, and try a few variations...) Given a reasonable set of controls that should have an accesskey, what should the value of that be? Something memorable, and if possible like something else. There is no point imagining that you will get universal agreement on what to use. Among Unix users there are two seperate groups - those who use vi, and those who use emacs. Most good Unix software lets you choose a keyboard shortcut preference that uses one or the other as a basis - they are different, and they are not going to be united. Similarly, different Windows screen readers have different control keys, and good ones allow you to select the "native" keyboard commands or change them to match something else you have become used to. Likewise, in spanish there are two terms in common use for "file" - "fichero" or "archivo". Which letter should be selected as memorable? (The same problem came up recently in choosing whether to use "biblioteca" or "librería" for a term). And most people in the US probably don't know how to generate Lucida Grandeب (the arabic character for "b") anyway, including people who regularly read Arabic, in my experience. This is no reason for people who write arabic all day not to assign it as a default accesskey on an arabic site. So we have a set of controls with allegedly memorable accesskeys. How should browsers handle them? This is something that browser makers should work out. Simply ignoring them makes for a pretty weak browser. Even if it provides a different feature like incremental search ("find-as-you-type" - first implemented in emacs before there was a web to browse, and much beloved of emacs users) Two possible approaches that browsers could use: One - the "iCab" approach: Don't use any plain characters for controlling the browser. This leaves them all available to select or activate the control (according to user preference, with luck). This is my personal favourite - for various reasons reducing keystrokes is important to me as a user - but it isn't everyone's preference. For extra credit, the browser could ask the system what keyboard is active at the moment. If I have an Australian keyboard running, and a page is in Arabic with arabic accesskeys, it could remap the keys to activate those controls to phonetically similar latin characters. (Lynx presents arabic pages in latin fonts by doing this mapping - it isn't technology that would need to be developed.) Two - the "pass-through" approach: In a browser like Opera which has very substantial and powerful keyboard control already, Mozilla which uses bare keys for its find-as-you-type functionality, or Amaya which allows editing using the bare keys, you need some other way to get at the accesskeys. This has already been figured out for screenreaders, which need to re-use controls, or allow the user to activate the underlying software with the same controls. For example, the browser might reserve the command-p key for pass-through. So to activate an accesskey the user presses command-P and then the accesskey. Or the browser might apply the accesskey as a default, and use command-P to allow the user to access other commands. There are more "extra credit" approaches possible too. The browser could, on the pass-through key, open a list of controls that have accesskeys. This would allow people to move up and down that very short list - similar to the headings list that systems like iCab or Jaws provide, or the links list available in Amaya, Lynx, or most screenreaders. There is a parallel to a lot of this in HTML - the link element. It is most commonly used at the moment to point to a stylesheet, and sometimes to an alternative version. But it is possible to point to the "next page" or "previous page", "contents" or "index" or "copyright page" or "help page" of a site. These links are then rendered in a browser-specific way - Lynx, iCab, Mozilla, Opera all show approaches to making these links available through the user interface. In this case the way of activating the link is the same for every site, because it is determined entirely by the browser. Authors can also define other link elements... cheers chaals On Monday, Feb 24, 2003, at 19:43 Australia/Melbourne, Jesper Tverskov wrote: Use first letter as ACCESSKEY www.klapmusen.dk/artikel.aspx?xml=20021031&lg=en (a new approach to the use of the ACCESSKEY) 1. If we always use first letter of the link text as ACCESSKEY, they can be generated by code. 2. We do not have to mark the access key letter, because it is always the first one. 3. We can have scores of access keys on each page, because the same access key letter can be used many times. Please read my article carefully, and think it over before responding. If we do it right, the ACCESSKEY could become a benefit to all keyboard users of the Internet. -- Charles McCathieNevile charles@sidar.org Fundación SIDAR http://www.sidar.org