W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2003

RE: HTML Techniques: 'tabindex'

From: Geoff Deering <gdeering@acslink.net.au>
Date: Wed, 12 Nov 2003 06:50:51 +1100
To: "Jens Meiert" <jens.meiert@erde3.com>, "W3C WAI" <w3c-wai-gl@w3.org>
Message-ID: <NBBBJPNFCLNLAADCLFJBIEHKFEAA.gdeering@acslink.net.au>

I second this question.  I would expect tabindex to flow in logical manner,
otherwise the forms, navigation, etc would indicate by this intended
approach to not be laid out in a logic manner.

I have also been thinking about another usability problem that I have not
seen addressed anywhere else, and this is the order of buttons at the end of
forms.  It seems to me there is no standard.  Just take "Ok" and "Cancel"
for instance.  Often they are in that order, but sometimes reverse, with no
obvious reason.  It appears to me that the most appropriate logic to follow
in design is to place the most affirmative action first (left to right /
right to left depending on the direction of the language).  So that if the
form is submission information you put "Ok" first, but if the form is
"Delete everything on you system", you put "Cancel" first, whatever would be
the action most likely to be firstly appropriate.  I know I have often just
pressed the first button on the left expecting it to be the affirmative
action and being a being disposed at times to projection rather than
perception, I have assumed the wrong action.

This also seems to fit in with what Jens is saying (I think); forms and
content need to be very logical and understandable in their behaviour.
Their should be an ease and flow, and that should only be broken when it is
logical to do so.

Of course, it makes sense when forms are dynamic and you are jumping fields
that you have triggered as read-only if that form contains such data sets,
so there are exceptions, but aren't we talking more about common law
behaviour and what the average user expects is in the natural course of work
and flow in navigation?

Geoff

-----Original Message-----
From: Jens Meiert

Before shooting first I want to ask what purpose the 'tabindex' handling
recommendation has, referring to the 'HTML Techniques for WCAG 2.0' [1]. In
9.5
[2] it is recommended, not to use the 'tabindex' attribute to leap e.g. a
set
of navigation links, but in another case (see 14.1 [3]) it is illustrated to
use 'tabindex' to change the (tab) order of form elements, what I perceive
as questionable (and per se contradictory), not only in relation to 9.5.

Can anyone of you please explain this to me? -- Normally I'd think it should
be recommended just the other way around, thus allowing to jump over e.g.
navigation links (because there should also be alternative <link /> elements
to
represent a site's structure, btw), but not recommending to violently change
the order of form elements (where I only see the risk to irritate users).

So I wonder (from Usability perspective, too), what sense the 'form case'
(and its example from 14.1) makes:

   <form action="#" method="post">
      <p>
         <input tabindex="2" type="text" name="field1" />
         <input tabindex="1" type="text" name="field2" />
         <input tabindex="3" type="submit" name="submit" />
      </p>
   </form>

If I imagine 'field1' represents a user's email address (which is displayed
first), ain't it 'curious' being at first asked for my name (as e.g.
expected
in 'field2'), when starting to access the form via pressing 'tab'? On the
other hand I often encountered cases where I really wished there was a tab
order allowing me to jump over a site's navigation. But, I didn't want to
shoot
first... ;)


All the best,
 Jens.


[1] http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS/
[2]
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS/#linkgroups_tabindex
[3] http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS/#form_tabindex


--
Jens Meiert
Interface Architect

http://meiert.com
Received on Tuesday, 11 November 2003 14:56:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:26 GMT