- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Sat, 21 Aug 2004 19:53:56 -0400
Ian Hickson wrote: > On Sat, 24 Jul 2004, Kai Hendry wrote: >>1) Users can not easily tell what the accesskeys are. >>2) Accesskeys can conflict with the UA binds. > > I agree that we should address these. > > I think UAs should automatically highlight the accesskey (or add it in > brackets if it isn't already in the string). I am thinking of writing some > text -- optional, of course, since this wouldn't apply to all UAs or all > platforms -- that specifies this. I don't think RENDERING of the access key should be optional. The vendor may implement rendering access keys as they see fit, but the user must have an immediate, obvious method of finding these keys without going through a set of menus or some similar obscuring nonsense. Here's the text I have for this currently: "User agents must render the value of an access key. Access keys should be rendered in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it). Vendors should make every attempt to render access keys in a way that is consistent with the native operating system or platform UI conventions. In cases where the access key is not contained in the label text, the access key may, if native conventions permit, be rendered in brackets or parentheses before or after the label associated with a control." > I also think that there should be an accesskey value which is basically > "auto", and which picks a non-clashing access key based on the element > content. What's the purpose of this? Are there really situations where there are so many access keys that the webmaster doesn't want to bother with keeping track of them and just wants them auto-assigned? I think it would be better to just check for overlapping |accesskey| values and just autoselect when there is a conflict. The text could go like this: "In the event that more than one element had the same value for the <code>accesskey</code> attribute, the first element to declare the access key should remain the same, while later access keys may be automatically assigned to an unused key, giving preference to unused keys that are contained in the associated label."
Received on Saturday, 21 August 2004 16:53:56 UTC