- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 03 Jul 2007 12:08:20 +0200
- To: "public-html@w3.org" <public-html@w3.org>
Hi, Summary: the HTML 4 markup is fine, but the existing specification is too vague in parts, and suggests (without requiring) implementation approaches that are harmful. So, here is an approach to specifying it better. It doesn't really talk much about how to implement, but there are various approaches. Experience (the bitter experience of a lot of implementations that are not very good, mostly getting one thing or other right and a lot wrong) suggests that it would be worth making it very easy to find such suggestions from the spec, but I haven't put them in here. I will write a response to this mail describing implementation strategies. Still lacking from this proposal: * how to handle empty string or more than one character (I suggest by putting them into the collection. Since, unlike HTML 4, this proposal uses the key as a hint rather than relying on it being available and convenient for the user to use, it doesn't really matter. One alternative is to allow any kind of string as content, and suggest that it should be a single key.) * what happens if an accesskey is added while a user is using the access mechanism? (In the current proposal it is not possible to detect whether the user is "in media res". Either the implementation adds something, or doesn't - it may, like iCab, have an effectively instantaneous mechanism anyway, or it may (should?) lock the collection while the author is in the process of selecting something) * how to handle multiple occurences of the same value in a page. (Make them work, but non-conforming? Same reasoning applies as for null/more than one character, I think. This is something I have seen in the wild). * what to do with iframes and popups. * Test cases. I will write these where they are not already available. [[[ The accesskey attribute creates a list of important navigation points in the document. This is an important strategy to provide rapid navigation for keyboard users and those for whom input is very difficult (mobile phones, people using switch access and similar). In many ways it is like providing keyboard shortcuts for common application or OS functionality, but should not interfere with those. This attribute assigns an access key to an element. Its value is a single character from the document character set. Elements with accesskey form a collection. User agents should provide a user interface for users to discover what elements are in that collection, and a rapid access mechanism for those elements. The rapid access mechanism must be able to focus the relevant element. User agents may provide a configuration to directly activate the element. The rapid access mechanism may use the assigned accesskey as an accelerator. Any focusable element supports the accesskey attribute. Adding an accesskey to an element makes it focusable. This example assigns the access key "U" (CAPITAL-U) to a label associated with an INPUT control. <form action="..." method="post"> <p><label for="fuser" accesskey="U">User Name <input type="text" name="user" id="fuser"></label></p> </form> Where a link can be described accurately using a technique with predefined semantics such as the rel attribute, authors should use that in preference to accesskey. This enables browsers to provide a standard interaction mechanism common to the entire web, not just for one site, for those functionalities. Authors may choose to use both, in order to offer functionality in older browsers, but increasing the number of accesskeys in a page reduces the overall effectiveness. In this example, we assign an access key to a link defined by the A element. Typing this access key takes the user to another document, in this case, a table of contents. <p><a accesskey="c" rel="contents" href="http://example.com/contents.html">Table of Contents</a></p> The invocation of access keys should not interfere with the underlying system. For instance, on machines running MS Windows, using the "alt" key in addition to the access key would in many cases interfere with default functions, so this should not be the rapid access method. The rendering of access keys depends on the user agent. Authors should not include the access key in label text or wherever the access key is to apply, since user agents may select another key or another method for activation.]]] -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk chaals@opera.com Catch up: Speed Dial http://opera.com
Received on Tuesday, 3 July 2007 10:08:35 UTC