Making Elements Focusable with Tabindex

After reading James Edwards' latest article on Sitepoint, Accessible JavaScript: Beyond the Mouse, I was intrigued by one section:

"... if we want to capture input from the keyboard, we'll need to use elements that can accept the focus: primarily links and form controls ... "

I quickly thought about simply adding the tabindex attribute to an element and after some preliminary tests in FF2/Win and IE7/Win it seems that's all that is necessary to make an element focusable.

After some discussion with Derek Featherstone, I learned some interesting stuff (and hopefully I'm describing this accurately).

The tabindex value can allow for some interesting behaviour.

  • If given a value of "-1", the element can't be tabbed to but focus can be given to the element programmatically (using element.focus()).
  • If given a value of 0, the element can be focused via the keyboard and falls into the tabbing flow of the document.
  • Values greater than 0 create a priority level with 1 being the most important.

I tend to shy away from trying to declare any tabindex as the regular document flow should be predictive enough but if creating a JavaScript-enabled interface, there may be times where tying something to a link actually doesn't make the most sense and having an element be able to receive focus via the keyboard as well as from the mouse can only be a good thing.

Published December 12, 2006
Categorized as Usability
Short URL:


12 Comments · RSS feed
Tim McCormack said on December 12, 2006

Hey, this is good stuff! Thanks for demystifying tabindex. (I've always been a little sketchy on what the values really mean.)

Jesse Skinner said on December 12, 2006

It's nice to know it's possible, but I can't think of scenario where you'd want to have a form element or link on the page, and not have it focusable via the keyboard.

Can anyone think of one?

Jonathan Snook said on December 12, 2006

Jesse: to clarify, it's a case where you might have a div (or other element not normally focusable by keyboard) that has mouse events attached to it. Giving it a tabindex will allow you to attach keyboard events to it, too, making it more accessible.

For example, let's say you wanted to create a tabbed interface for some information on the screen. The headings for each section could be the tabs. Having them as links doesn't make much sense since the links wouldn't go anywhere. But having them as keyboard focusable means you could set up onfocus events to bring the selected tab to the forefront.

Jason Kataropoulos said on December 13, 2006

Funny, I was playing around with this a few days ago.

Anyway, I am sure that there are scenarios that proper tabbing is important and can add up to usability. I personally found that it can be helpful not only for disabled people.

Derek Featherstone said on December 13, 2006

Just thought it might be worth pointing to the HTML spec for tabindex

Matt Wilcox said on December 13, 2006

From the HTML spec: "This value must be a number between 0 and 32767"

I would imagine this is why the element given a tabindex of -1 is not focusable; because it's an invalid value. Programmatic access wouldn't care if the value of the attribute was valid or not though, which would be why you can access it through JavaScript.

What happens if you leave the value blank? Would that emulate the action of a -1 value, or a zero? Would it even be valid code?

Lance Fisher said on December 13, 2006

Derek, I checked out the W3C spec, and indeed it doesn't specify what a value of -1 should do. However, in both the Firefox Documentation and the IE Reference it is specified just as it is mentioned here.

Matt, if you include the tabindex attribute, but leave it blank (tabindex=''), it will behave like the attribute is not there. i.e. Focusable elements will be able to receive focus, and non-focusable elements won't be able to receive focus via the keyboard.

Good post, Jonathan.

Jesse Skinner said on December 13, 2006

I guess I meant, when would you ever want to use tabindex="-1". I can't think of a scenario.

But giving tabindex to non-links/form elements is a cool idea.

Matt Wilcox said on December 13, 2006

Lance: Cheers for clearing that up, you are saying it behave like a 0 (is focusable, but in natural flow).

"the W3C spec, ... doesn't specify what a value of -1 should do" - that's because it specifies a value of -1 as being outside the legal range. I believe it is then up to the browsers as to how to treat an illegal value. Ideally I suppose, they would simply ignore the attribute.

Lance Fisher said on December 13, 2006

Matt, using tabindex='' is slightly different than using 0.

On a div:
If you set tabindex='0' it becomes focusable and in the natural flow, but if you set tabindex='' it is not focusable at all.

On an anchor:
If you set tabindex='0' there is no change from tabindex='' since anchors are normally focusable.

If it turns out to be useful, perhaps the W3C should add the -1 behavior to their recommendation.

Emrah Baskaya said on January 21, 2007

I am already using this technique to give my custom scrollbar solution keyboard accessibility, it surely works wonders, and more authors need to embrace this solution (e.g. a dynamic navigation menu that uses javascript should also cover for people that browse with keyboards. Not that I have done it for my own site yet but I am just blubbing!)

Also worth mentioning is, AFAIK, Opera has a keyboard navigation system that emulates mouseovers on anything that has onmouseover attached to it, allowing it to give keyboard focusability as if one was using a mouse, which is simply a nice feature.

Rahul said on December 21, 2008

But in certain cases TabIndex = 0 does not set the cursor at the control when form gets activate.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.