Re: HTML Techniques: 'tabindex'

Yes that is a good example of contradiction... skip navigation link and  tabIndex cannot co-exist. I am not sure it is a user agent problem but a matter of logical flow  of how   one should navigate the links. The need for tabindex for links arises chiefly when links are placed in a layout table and  logic dictates for instance that one should read down one column and then proceed to the adjacent column. So tabindex might be a good thing to have.
So  the HTML technique should  suggest: use tabindex for links on pages where  other navigation controls like skip nav are not being employed. 
And where it is necessary to use a skip nav link, the author should attempt to arrange the links so as to obviate the need for tabindex. 
  Sailesh Panchang
  Senior Accessibility Engineer 
  Deque Systems,11180  Sunrise Valley Drive, 
  4th Floor, Reston VA 20191
  Tel: 703-225-0380 Extension 105 
  E-mail: sailesh.panchang@deque.com
  Fax: 703-225-0387
  * Look up <http://www.deque.com> *



  ----- Original Message ----- 
  From: Michael Cooper 
  To: W    3C WAI 
  Sent: Tuesday, November 11, 2003 2:35 PM
          Subject: RE: HTML Techniques: 'tabindex'



  Hi Jens - there are a couple reasons the recommendations appear as they do
  in the HTML techniques: we aren't always sure in all cases what we should
  say, and in a case like tabindex where it appears in multiple places in the
  document, we haven't yet gone through the editorial process of making sure
  the whole document is self-consistent.

  The reason the current draft recommends against tabindex for links is that
  we have been presented with evidence that doing so actually causes problems
  for accessibility. The favourite example is if you use tabindex and skip
  navigation links on the same page, then the user follows the skip navigation
  link, the tabindex could undo the benefit of the skip link and take them
  back to the top of the page, rather than continue in the tab order from the
  new location. We consider this a user agent problem, not a problem with the
  use of tabindex in theory, but a sufficiently widespread problem that we
  felt it was best to say in so many words, "don't do this for now". Thus,
  what we want to do really is have one technique that says "don't do this for
  now and here's why" and another that says "here's how in the future one
  should be able to use tabindex, but user agents don't support this properly
  yet so we don't expect conforming sites today to follow this technique". We
  haven't figured out how to express that yet in the structure we've created,
  and I guess the current expression isn't working since you were confused.

  Tabindex for forms is different in part because of editorial oversight, but
  also in part because we have some open questions about it: In current user
  agents, is tabindex for form controls in a different "tabspace" than
  tabindex for links? Should it be? Should it explicitly not be? These may
  seem like arcane questions, perhaps with obvious answers, but in discussion
  we didn't resolve them in the timeline of this draft. Some people have
  homework assignments to look into this.

  I would say therefore that your confusion reflects in part the confusion we
  have. Your thoughts and recommendations will be helpful next time we open
  the books on this issue. So, don't shoot us down, but do fire away with your
  thoughts!

  Michael

  > -----Original Message-----
  > From: Jens Meiert [mailto:jens.meiert@erde3.com]
  > Sent: Sunday, November 09, 2003 8:38 AM
  > To: W3C WAI
  > Subject: HTML Techniques: 'tabindex'
  > 
  > 
  > 
  > 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/#linkgrou
  ps_tabindex
  [3] http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS/#form_tabindex


  -- 
  Jens Meiert
  Interface Architect

  http://meiert.com