Re: HTML forms

   Date: Mon, 3 Mar 1997 18:04:40 -0500 ()
   From: Dave Raggett <dsr@w3.org>
   cc: scotti@microsoft.com, www-html@w3.org
   X-X-Sender: dsr@anansi.w3.org
   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?

Received on Monday, 3 March 1997 20:25:42 UTC