This course has been updated! We now recommend you take the Website Accessibility, v2 course.

Check out a free preview of the full Website Accessibility course:
The "Tabbable Elements" Lesson is part of the full, Website Accessibility course featured in this preview video. Here's what you'd learn in this lesson:

The basics of keyboard navigation depend on tabbable elements. Jon reviews which HTML elements are natively tabbable and how to manipulate elements to become tabbable through the tabindex attribute.

Get Unlimited Access Now

Transcript from the "Tabbable Elements" Lesson

>> Jon: So the basics of keyboard navigation. We've talked about that we should have keyboard navigation, but we haven't really talked about how that works. And so it basically all comes down to the Tab key, and tabbable elements. So the basic concept is that on any website, hitting the Tab key will move you forward one item, one tabbable item.

[00:00:20] This works on all websites. And then hitting shift and the tab key will move you backward one item. So you can kind of tab, tab tab, shift tab, shift tab. And that's the way a lot of people are going to be going through your site. For those wondering what tabable elements are, the most popular ones.

[00:00:35] There's a longer list which we'll get to in one of the exercises are anchors, buttons, any type of input or select, text areas, and then iframes. And so what we're kinda talking about here is if you have let's say a basic site and you've got a a div, that's not gonna be tabable, then you got a UL, not tabable, and then inside those list items maybe you have anchors, those are going to be your first tabable items.

[00:01:00] And then maybe later on, you've got a form or something like that. And so I didn't mean to kind of start thinking about the idea here is that, especially like was mentioned earlier. Websites have a ton of mark up. So you wouldn't want every element to be because then you'd be tabbing for hours, so the presentational items, like div, span, things like that, they don't get to be tabbable by default, cuz there's no real purpose there, but the stuff that you would interact with, like a link that you would click, or an input where you would enter some data, those come tabbable, so it's just kind of a way anything that you would be interacting with comes tabbable by default.

[00:01:34] And this starts to play into what we were talking about earlier with that comment about using the correct mark-up for correct things. So I was a little careful with my words, saying things like divs and spins aren't tabable by default, which is true. But any item can be either made tabable or not tabable by the users.

[00:01:56] Or by developers rather. And so the idea here is that there's this HMO property called Tabindex and so you can take something like this div which says I'm focusable but by default would not be focusable right so it's a div. And you can add tabindex 0, and you'll refresh the page, and then as your tab aim through it'll highlight that div as a focus for item.

[00:02:17] So tabindex this is a lot of words, but there's only three values really that tabindex can take. And like we see appear it's just a HTML attribute. Tabindex equals, so it can take a negative value, which means that it is focusable but it can't be reached via tabbing around.

[00:02:34] So this would be something that we wanna call focused on with JavaScript. So we want it focusable, we don't want it part of the users tabbing through. Give it a zero, and it just turns into a focusable not item wherever it falls on the HTML. If you wanted a did kinda act like a link.

[00:02:51] You can make it focusable with zero and it'll get tabbed too when it gets tabbed too. Then a positive value, which I think is kinda little bit often an anti-pattern. It's kinda like z index. Right? It's making it tabable and then you're kinda bumping it up, like your bumping it up in order.

[00:03:11] So the only places, I've seen these used in cool ways for advanced accessibility stuff. So for example, on Twitter, when you go to Twitter with a screen reader on and you hit Tab for your first movement, it starts reading you this thing that's not visually there on the site.

[00:03:28] It's like hey, we have some keyboard shortcuts hit question mark if you wanna check them out. And so how that's achieved is that there's this you know div or a span and it's like stuck in the document somewhere and it's given that really high tab index. So, it's the first thing that gets tab to.

[00:03:42] So, that's kind of like an intentional use of it, where you have a visually hidden div that's trying to communicate with screen reader users. But other than that, you should probably let things fall in their tap border.
>> Speaker 2: So does it go the highest value first and then on down?

>> Jon: Yeah, yep. So yeah, it's kinda and then there's a couple places it's an empty pattern one of them is like trying to be pushy with screen readers like screen readers are good and often times you should just kinda let them sort things out but also you kinda get into similar z index battles over.

[00:04:19] Yeah.
>> Speaker 3: Another comment again from Jack. John spoke to items being focused of all by default browsers show focused indicator. Think of a colored rectangle, many CSS resets 0 out that styling so, the developer, you may need to add back to style the show the focus indicator.
>> Jon: Yep, definitely, yeah we've got a couple slides devoted to focus for items.

[00:04:40] But it's one of the WebAIM checklist items that we're gonna check over is that making sure users have a visual cue to where they're at with focusable items. So, if you think about a form and a keyboard only user and there's 20 inputs and they're tabbing through all of them.

[00:04:55] They should be able to look, you should be able to look at any time and be able to see which one you're at. By default, Chrome has that blue focus ring around index items. But, yes a lot of times frameworks or resets remove that because they, the design wants that and that can be a big, a big no no for accessibility.

[00:05:15] Does that make sense though on tabindex though?
>> Speaker 4: Question about negative value, so it's focuable but not sequentially how do you typically get to it?
>> Jon: You would use JavaScript to focus on it. So, like say for example. You have like kind of a single page so I have this great example and then Chrome patched the problem for but my great example is a single page website so you click on links at the top and it scrolls you to a view port down.

[00:05:42] So but, until recently, so if you would click on it and you would scroll and down then you'd hit tab, probably what you'd want is to start tubbing from the item but what happen is you would start tubbing from the top of the document really frustrating. So, the thing you could do is to take the titles for those single page websites and you could put a negative tab index on them so you would never hit, but what you can do is when you have a list and they're on the link, So when the link clicks it moves, and then it calls that focus on that header.

[00:06:09] Something like that. So now, you're focuses there, so if you hit tab the focus will start there, and keep moving, and things like that. So, you have the negative one is like saying, I'm gonna control this, like I don't want users to hit it with tab, but it do need to be able to call that focus on there.

>> Jon: I thought this was really funny. So on MDN, the maximum value in tab index should not exceed 32,767 per the W3C. I think if you get anywhere near there, there's problems. I think more common is people hitting 9999, trying to get the top precedence. I just thought that was a funny note.