- From: Tom Croucher <tcroucher@netalleynetworks.com>
- Date: Sun, 28 Sep 2003 11:37:42 +0100
- To: "'Roberto Scano - IWA/HWG'" <rscano@iwa-italy.org>, "'Gian Sampson-Wild (PurpleTop)'" <gian@purpletop.com.au>, "'Charles Oppermann'" <charles@coppersoftware.com>, <w3c-wai-gl@w3.org>
I don't think it is CIOB's prerogative to ride rough shod over these things. While suggesting that the use of '1', '2', and 'm' as accesskeys is inadvisable it is still a UA issue how they cope with accesskeys. Accesskeys have been around long enough so that UA have had time to integrate them into their navigational systems. I think the use of accesskeys is important because they allow semantic mapping which are too complex for even the cleverest technology to work out on its own. While assistive technology browsers may allow skipping between paragraphs headers and many other combinations of things accesskeys gives the page author the power to link directly to (groups of) semantically defined items. So for example a user can skip from anywhere in the page straight to the search form, the navigation or specific parts of the navigation depending on how the accesskeys have been laid out. Yet the browser manufacturers in their wisdom have decided that their keys are more important, or worse that they will use the same keys till they are overruled. While I accept that much of the power behind much assistive browser technology relies on combination of key strokes, I think it is important to give accesskeys a reserved slot. If alt+h might be an accesskeys or it might be a whole new help window, it will quickly become frustrating if (being human) you can not remember if a page has an 'h' accesskeys or not. I do however think that Jukka Korpela's point (as Gian pointed out) that '1', '2', '3'... rely on QWERTY (or Dvorak) keyboards is something we should note. This is much less of a UA issue and more of a cultural one. There was some discussion this week of allowing for other cultures and looking for ways to support them. One of the concerns raised was Japan not wanting to use WCAG 1.0 because they felt it was not appropriate to particular issues. This could well be one of those issues if we recommend something that is culturally inappropriate. However as I said before accesskeys should be translated into other languages as content and menus should be, if they are translated as concepts rather than keys these cultural differences can be addressed. You can refer to my sizable mail on Friday 26th for information on how we did this on the Plone project. Splurging, Tom Co-founder Netalley Networks (http://www.netalleynetworks.com), BSc(Hons) Computing Student / Information Services Staff University of Sunderland (http://www.sunderland.ac.uk), Accessibility Co-ordinator Plone CMS (http://www.plone.org) -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Roberto Scano - IWA/HWG Sent: 28 September 2003 10:26 To: Gian Sampson-Wild (PurpleTop); 'Charles Oppermann'; w3c-wai-gl@w3.org Subject: Re: Accesskey: there are "techniques"? ----- Original Message ----- From: "Gian Sampson-Wild (PurpleTop)" <gian@purpletop.com.au> To: "'Charles Oppermann'" <charles@coppersoftware.com>; <w3c-wai-gl@w3.org> Sent: Sunday, September 28, 2003 11:18 AM Subject: RE: Accesskey: there are "techniques"? > > The other problem with numbers is that at least one is used by a screen > reader: IBM Homepage Reader uses the numeral 1 to begin reading in > heading mode. See: http://wats.ca/resources/accesskeys/19, which > specifies that the only 'free' ascii keys are: > AccessKey / (slash) > AccessKey (backslash) > AccessKey ] (right square bracket) > Note: "At that point it was then pointed out (by Jukka "Yucca" Korpela - > a well respected accessibility expert) that even these keys would be > inaccessible to users not using a North American Standard (QWERTY) > keyboard" Hum... also interesting the reference for the canadian government web sites: http://www.cio-dpi.gc.ca/clf-upe/6/skip_e.asp At least... accesskey should be used or not? :-/
Received on Sunday, 28 September 2003 06:38:14 UTC