I’m employed for about a year now and many things are different compared to being a freelancer. One interesting thing in my specific situation is that I have to evaluate the accessibility of third-party tools regularly. Usually there’s no time for a full audit, I have to gain a good overview of the quality of a product as quickly as possible.

I’ve already shared 6 things I check on every website I build, but this time I want to focus on one of the most powerful testing tools: The Tab key.

Let’s say, you’ve managed to score 100 on the Lighthouse accessibility audit. This doesn’t necessarily mean that your site is accessible, you’ve just laid the groundwork for the actual testing. A next step could be putting your mouse away and using the keyboard only to navigate your site.

Here’s what pressing the Tab key will tell you about your website:

1. Focus styles

If you press the Tab key, do you see which item on the page is highlighted? No? Use :focus{ } , :focus-within{ } , or :focus-visible{ } to style elements in their focus state.

Beautiful focus styles on Carie Fishers website.

a:focus {

background-color : #b426ff ;

outline : 5px solid #ea3bcb ;

}

Learn more about focus styles

2. Interactive elements

Can you reach interactive elements like links, buttons, form elements, or video controls? No? Work on your HTML. You’re probably using <div> , <span> , <svg> only, etc. where you should be using <input> , <button> or <a> .

Don’t use div s for buttons. This fake button is not accessible to keyboard and screen reader users.

< div class = " btn " onclick = " send() " >

Send

</ div >

Do this instead:

< button class = " btn " onclick = " send() " >

Send

</ button >

3. Real buttons

You can reach a button, but nothing happens when you press Enter or Space ? It’s probably still not a real <button> or <input type="button"> .

You can make fake buttons tabbable and you can change their semantics, but you only get key events by default with real buttons.

< div class = " btn " tabindex = " 0 " role = " button " onclick = " send() " >

Send

</ div >

Do this instead:

< button class = " btn " onclick = " send() " >

Send

</ button >

Learn more about buttons

Do you have to tab through a lot of elements before you can reach a certain part of your UI? You probably want to implement skip links.

Skip link on Tatiana Mac’s website.

5. Focus management

When you press a button and a modal/dialog pops up, can you access its contents immediately? No? You probably have to shift focus from the button to the modal.

function showModal ( ) {

...



lastFocusedElement = document . activeElement ;



var modal = document . getElementById ( modalID ) ;

modal . focus ( ) ;

...

}





function closeModal ( ) {

...



lastFocusedElement . focus ( ) ;

...

}

6. Infinite scrolling

Do you have a footer but you can’t access it by pressing TAB because you’ve implemented infinite scrolling? Burn it, burn it with fire!

No, seriously. Infinite scrolling is usually a bad practice.

Learn more about infinite scrolling

7. Off-screen items

Does the focus indicator suddenly disappear while you keep tabbing? It’s likely that you’re focusing off-screen items. You have to hide them correctly. height: 0 , transform: translateX(-100%) , etc. don’t remove items from tab order, display: none; does.

See the Pen Inaccessible hiding by Manuel Matuzovic (@matuzo) on CodePen.

8. DOM order

Does the focus indicator skip around a lot? Most of the time it’s because visual order doesn’t match DOM order. Try to avoid reordering logical content and don’t use higher values than 0 as a value in the tabindex attribute.

Learn more about source order

9. Custom JS components

Are only parts of your JS components accessible with the keyboard? Read the WAI-ARIA Authoring Practices to learn how to build common patterns correctly and make them accessible to everyone.

The Tab key is awesome

You don't need to learn a software to get started with accessibility testing, the Tab key will tell you a lot about the quality of your website. There’s more you have to check, but testing with the keyboard brings you one step closer to creating an inclusive website.

This post is based on a twitter thread from last year.