Date: Mon, 3 Mar 1997 20:23:43 -0500 Message-Id: <199703040123.UAA12274@churchy.gnu.ai.mit.edu> From: "nemo/Joel N. Weber II" <email@example.com> To: firstname.lastname@example.org CC: email@example.com, firstname.lastname@example.org In-reply-to: <Pine.WNT.3.95.970303173204.111Eemail@example.com> Subject: Re: HTML forms Date: Mon, 3 Mar 1997 18:04:40 -0500 () From: Dave Raggett <firstname.lastname@example.org> cc: email@example.com, firstname.lastname@example.org X-X-Sender: email@example.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 3 Mar 1997, nemo/Joel N. Weber II wrote: > These comments are regarding the `Design Issues for HTML Forms'; > the draft is at http://www.w3.org/pub/WWW/TR/WD-forms-970203 > > The name `accesskey' seems unintuitive to me. I'd prefer something that > doesn't look like a name invented by marketing people. `key' and > `shortcut' and `hotkey' and `keystroke' are all names that I would > consider an improvement over `accesskey'. Personally, I prefer shorter names where the meaning remains clear. In this case its also a matter of achieving consensus in W3C's HTML working group. None of the four names I proposed were longer than 'accesskey'. I just checked htmlpro.dtd, and it appears that they only place 'key' is used is in <cite> and <dfn>. So I think we could reasonably use just 'key'. I doubt the other three of my suggestions or accesskey would cause namespace problems. I'd appreciate thoughts from other people, especially Peter Flynn and Galactus. Globally assigned keys cause difficulties in compound documents. The author assigned key may conflict with the operating system, with the UA (e.g. the menus or toolbar) or with other objects in the hierarchy defining the document. AccessKey emphasises the importance of using keystrokes to *access* the document elements by people with disabilities. Can you explain to my why this feature makes web pages more accessible to disabled people? lynx can already handle textmode web navigation without this feature. Also, it only helps if authors bother to assign keys. Experience with Netscape-only pages suggests many people won't bother. I don't really see a strong connection between this feature and disabled people. Furthurmore, it's very useful to advanced users. One way around this is to switch to a navigation model. A sequence of key strokes traverses the hierarchy taking you to the specific element you intended. Microsoft Windows uses this approach with ALT+key for accessing menus etc. I don't really want to see a hierarchy of keystrokes. It probably will get too hard to navigate. On Windows ALT+key is appropriate. On other platforms other choices are needed. For the Mac an additional modifier key may be needed to avoid clashes with global command keys. Another combination may be appropriate for X11. The spec is being revised to make these issues clearer. I would suggest we recomend control on both the Mac and on X11. In theory, control is reserved for macro packages on a Mac. But I've never seen a macro package that uses the control key; the control key is usually only useful for telnet. And on X, the control key is not likely to be used in anything except shell windows. Also, it's one of the few modifiers that seems to exist on almost all X terminals (sun keyboards don't have a key marked 'alt'). This allows the server to initialize a given field as being disabled e.g. because the current state of other fields precludes this field from being changed. With scripts the disabled flag can be modified dynamically rather than awaiting the processing of a submitted form. Is there any reason we couldn't include info with the form so that you don't need a script to have a control enabled and disabled according to the state of another control? > The label proposal makes sense to me; except that putting the accesskey > on the label and not the object it describes makes no sense to me at all. This is debateable. But the key activates the button, not the label describing the button. If you click on the button, something happens. If you click on its label, I don't think anything happens. So why would keystrokes make more sense on the label than the button?