- From: Markku T. Hakkinen <hakkinen@dev.prodworks.com>
- Date: Wed, 24 Jun 1998 18:43:33 -0400
- To: <w3c-wai-ig@w3.org>
I am afraid there are UI consistency problems between "standard Windows Dialog conventions" and web forms. In Windows (and Mac), the default action/button is made clear to the user by a dark, thick button border. In web forms, the default is the submit. From a UI consistency point of view, this should be addressed. In a self-voicing browser like ours, we can optionally announce the fact that the submit button is the default. Is it important or desirable to add an attribute to the button to indicate which is Default? This allows something other than the Submit to be the default, and allows the UA to decide how to render it. Accesskeys (keyboard short-cuts) exhibit another problem. In windows dialogs, the accesskey is shown in dialog labels and buttons as an underscore, and in dialog editors, the accesskey is defined in context using the & character (example: &Send E&xit). This is not possible in HTML and requires some extra work to get the same visible effect. This makes me wonder about the design of the accesskey attribute, and whether there is not a better solution. And in our browser we have the problem of the potential conflict between browser built-in shortcut keys and those defined on the form. We allow complete user keyboard re-mapping of all browser functions and face the question, which takes precedence? IE appears to give precedence to the form's accesskey, which has the side effect of disabling previously accessible browser functions. Is this desirable for the user? We don't think so, and at this point we are not going to enable accesskey support in our code. Mark Chuck Opperman wrote: > This is just like a regular Windows dialog, where pressing Enter on a > control that does not use Enter (like a radio button, check box, > single-line > edit control) activates the default button, usually the Ok button.
Received on Wednesday, 24 June 1998 18:42:47 UTC