- From: Gez Lemon <gez.lemon@gmail.com>
- Date: Wed, 18 Jul 2007 10:41:35 +0100
- To: "Ben Maurer" <bmaurer@andrew.cmu.edu>
- Cc: "Charles McCathieNevile" <chaals@opera.com>, wai-xtech@w3.org, "Colin McMillen" <mcmillen@cs.cmu.edu>
On 18/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote: > On Wed, 18 Jul 2007, Charles McCathieNevile wrote: > > accesskey is designed to provide accelerated access to things. It is badly > > specified, and badly implemented in some browsers, but it is still about the > > best there is. And can be well implemented on the same markup. > > Agreed, that's one potential way to do it. I'm worried if it's > discoverable enough though. A bigger concern in your case is that you will need to choose accesskeys that don't conflict with those provided by the author of the page. You can't guarantee that any key you choose isn't already chosen by the author. You could let the author specify their own accesskeys when they include your widget, but that unnecessarily complicates using the widget (one of your primary goals is ease of use), causes problems with consistency, and if an author is already making extensive use of accesskeys, might mean there are none left to specify. To keep this in perspective, we are only talking about three links; "Get a new challenge", "Change the type of challenge", and "Help". Tabbing over those three items to get to the submit button is not a usability issue for anyone (particularly as keyboard users can press return to submit the form). Not being able to tab to those items with the keyboard is a usability issue, as they're pretty important functions that need to be available to keyboard users in an expected way. Gez -- _____________________________ Supplement your vitamins http://juicystudio.com
Received on Wednesday, 18 July 2007 09:41:37 UTC