- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Fri, 29 Aug 2003 09:44:46 -0400
- To: "Charles McCathieNevile" <charles@sidar.org>, <carl.myhill@ps.ge.com>
- Cc: <w3c-wai-ig@w3.org>
Carl, As Chaals points out, there *is* a standard already in place for providing a basic "uber-navigation" to any site, the relative link (http://www.w3.org/TR/REC-html40/types.html#type-links); "User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar." The fact that not all browsers properly support the standard is too bad, but currently Opera 7 has some implementation, as does the latest builds from Mozilla (curiously it seems absent from Netscape 7), and the oft maligned but rock-steady Lynx browser, (to name 3 that I am aware of). We are currently employing this at our web site (www.wats.ca) But consider for a moment the *primary* (not exclusive) reason for providing keyboard based navigation through a web site. When queried, most developers will say that it assists visually impaired users, which is certainly true. Oh ya, others may benefit from it (mobile devices, mobility impaired users, etc.), but this seems to be the major reason for implementation. Thing is, for how many years now, most if not all web developers have essentially ignored the Accesskey attribute... heck there are still those out there ignoring CSS. And so, the developers of the screen reading software took it upon themselves to implement functionality above and beyond what the web page developers were implementing. Thus tools like JAWS, HomePageReader and WindowEyes have pre-assigned keyboard shortcuts which allow the user to achieve much if not all of the functionality that you are now seeking to implement with Accesskeys. But, (and this is the big but), because it is software based, the end user has a greater assurance that it will work consistently across all sites, not just those "crafted" with the developers idea of what the navigational scheme should be. For example, in JAWS (which most will concede is the "Coca-Cola" of screen readers), users can bring up lists of Headers in a page (INSERT + F6, *and* it implements a system where-by the Headers act essentially as named anchors, allowing inter-page navigation), a list of links in a page (INSERT + F7, ordered either alphabetically or chronologically), and so on. (A list of keyboard shortcuts associated to JAWS may be found at http://wats.ca/resources/jawskeystrokes/9, IBM HomePageReader shortcuts at: http://wats.ca/resources/accesskeys/19; we're currently working on WindowEyes and Lynx keystrokes charts). Because of this, structurally valid (i.e. Semantically valid) code allows the users of these tools to seek out and access the information they are coming to your page for, with no extra effort or "magic" on your end. Don't get me wrong, the *idea* of Accesskeys, when added to the HTML spec, is/was a good one. However, due to it's lack of universal implementation, and the fact that there are differing keyboards out there (as Chaals points out), conflicting keystroke combinations which may or may not be over-ridden by other technologies/software, alternative means of achieving the desired result, etc., etc.,.... well, it reaches a point that attempting to add Accesskeys may in fact be detrimental to the end result. As you have pointed out: > > Until we get to the stage where access keys for websites are this > > consistent, surely the access keys themselves are not going to help > > much. Unfortunately, methinks we have come and gone beyond this point. The jury is already out, and Accesskeys seems to be left by the wayside. I would argue that the Accessibility community should push instead for wider and more standard implementation of the other existing standard, the relative link, at both the development end (our jobs) and at the implementation end (the web browser's job). If the usage of the established <link rel> elements became more accepted and used, those adaptive technologies which take advantage of keystroke combinations could internally "standardize" their usage - remember, "User agents, search engines, etc. may interpret these link types in a variety of ways.". IMHO, it's still not too late to resurrect the <link rel> attribute, and lists and groups such as this should push for it instead of trying to put the Accesskey genie back into the bottle. JF -- John Foliot foliot@wats.ca Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca 1.866.932.4878 (North America) > -----Original Message----- > From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On > Behalf Of Charles McCathieNevile > Sent: Friday, August 29, 2003 12:56 AM > To: carl.myhill@ps.ge.com > Cc: w3c-wai-ig@w3.org > Subject: Re: Standard access keys? > > > > There is a standard here, which is the rel attribute, as applied to the > link or a element - it means that a user can expect their browser to > provide a consistent way of navigating important links that is part of > the browser. > > Accesskey provides a mechanism for extending that in a particular way - > identifying the controls used on a particular page that are frequent > navigation stops (login, current status, top of the page, find the > nearest physical contact, cheapest option are all candidates in work I > am currently doing, which is quite different to the ones I wanted to > have a year ago). > > In situations where people are using different keyboards, and making > millions of websites, it seems hard to pick the 40 or so most common > keys and functions. When I use the arabic keyboard I don't have the > unicode characters "0123456789" readily available, nor any of the > letters "abcdefghijklmnopqrstuvwxyz", so anything that relies on those > to make life easier doesn't work. (But I have control characters > available, which means I can use system-standard shortcuts). > > If there is a convention compatible with what you need then using it is > better than creating something different. But there are limits to what > can be achieved... > > cheers > > Chaals > > On Thursday, Aug 28, 2003, at 21:00 Australia/Sydney, > carl.myhill@ps.ge.com wrote: > > > > > Thanks for the input on this. > > > > I'm afraid I find it a bit outrageous that there is not a standard > > quickly > > emerging here. On most Windows Apps, and on the Mac too, there are > > well > > defined standards for the basic shortcuts that are pretty much always > > dependable (unless you use EMACS) ... > > F1 > > Ctrl+S > > Ctrl+N > > Ctrl+C > > Ctrl+V > > Ctrl+X > > > > Until we get to the stage where access keys for websites are this > > consistent, surely the access keys themselves are not going to help > > much. > > If a disabled user knows that 'Alt+S' will always be the key to skip > > navigation on a site that has access keys, this is effective. If they > > need > > to learn what the access keys are for each website - it would seem to > > be > > more in the way of accessibility than aiding it. > > > > I've adopted the UK government guidelines because they seem to be > > bedding in > > as a kind of standard (although the analysis here > > http://www.clagnut.com/blog/193/ shows the limitations and conflicts > > with > > other standards). The UK government publishing folks are generally > > pretty > > sensitive to multi-cultural needs of our society so I am not worried > > about > > country specificness here. > > > > I don't personally think much of using numbers for access keys because > > they > > are not as meaningful as letters. It seems easier to me to remember > > Alt+S is > > for 'skip'. However, this is an English only view of the world, so > > numbers > > would seem to be more univeral. > > > > www.aquariusclub.net > > > > I'm not building a website for anyone with any particular needs. I > > want my > > design, and others, to be universal. So, I'm making my access keys > > visible > > on screen and accepting that it makes the design look slightly strange. > > Perhaps this is good strange - like buildings that once had grand > > steps to > > the door and now have a ramp. It might not look pretty but why exclude > > people when you don't really need to. > > > > I feel quite strongly about this - is there a formal way to elevate > > such > > issues to the WAI formerly? This would seem to need sorting out > > internationally. > > > > Carl > > > > > -- > Charles McCathieNevile Fundación Sidar > charles@sidar.org http://www.sidar.org > > > >
Received on Friday, 29 August 2003 09:44:50 UTC