Keyboard focus is crucial for accessibility, benefiting those with physical hand/arm issues, dyslexia, and low vision. We cover how to test for visible focus.
- A 3:1 contrast ratio is required for visible focus, with a double outline preferred over dotted or single pixel outlines.
- Test keyboard focus by using the tab key, shift+tab, arrow keys, return, space bar, and escape keys to navigate elements.
- Ensure focus is visible, not partially obscured, reaches all elements, follows logical visual order, is contained in modals, and is never trapped.
- Use semantic markup for accessibility, avoiding issues caused by lack of semantic markup with excessive JavaScript.
- Modal windows or popouts should take focus, allowing interaction, dismissal, and content readability.
Transcript
Welcome back to the Easy A11y Guide channel and the Quick Audit series. In this video, we’ll be discussing keyboard focus and how to test for it. The key requirements for keyboard focus that we’ll be testing in this video are visible, not fully obscured, reaches all elements it should, goes in logical visual order, is contained for modals, and finally, is never trapped.
Visible focus requires a 3:1 contrast ratio. People with physical hand or arm issues will frequently use keyboard navigation. People with dyslexia may use keyboard navigation to help them focus. People with low vision may be using keyboard navigation as the cursor is difficult to locate.
Generally, we like to see a 2 pixel solid or dashed outline for the visible focus. We don’t like to see dotted, especially not 1 pixel dotted, or even some websites I’ve seen a half pixel dotted. It is so incredibly thin in appearance that people just can’t see it, and it incredibly fails the 3:1 contrast ratio.
A double outline is generally preferred. Now we’re going to talk about testing for a focus. To do this, we will use our keyboard. We’ll put our cursor in the navigation bar, and we will hit tab to go through the different elements on the site.
We can use shift, holding down the shift key and then hitting tab to go backwards. Occasionally, we will find that elements need to use arrow keys. This is common, for example, with tabs. Return will submit a button or a link. Space bar will activate only a button but not a link. Finally, the escape key will allow us to get out of certain situations.
Testing focus visible
Let’s get testing. Here we are on wordpress.com. The first focus shows up. It is the second I can navigate into these and see the items. Here you’ll see that the focus state might be partially missing, i.e: on the right and left sides of this menu, I can’t see the focus indicator. That’s okay. Focus can be partially obscured, but we do need to make sure that any important content, such as the words, are fully visible.
Now, here we’ll notice that on the login button, we have a lighter blue against a brighter blue background. But then when we go to the Get Started button, we have a very light blue against a white background. This is going to fail our color contrast because it is a very subtle difference.
The contrast ratio is probably about 1.5. I’ve hit the tab key, and honestly, I have no idea where it went. It left the Get Started button. It doesn’t look like it went to the Get Started button that’s in the middle of the page. It just went somewhere. This would also be an issue when we have lost the focus and we have no idea where it is.
Now we have jumped down to the Explore Hosting button. This one we can see has a white outline and then a blue outside of it, and that’s a couple of pixels in thickness, and that really makes things easier to read. Now we’re going to take a look at another website.
Here we are on the W3C website. Here they use a focus state that is a double outline, yellow with black, so that the focus indicator has enough contrast with itself. We can see the clear focus state as we go between different elements. Here we are on another side, the Easy A11y Guide. We have a skip to content link that’s currently highlighted. Then we’re moving on to another element. This uses a double outline, a blue outside and white dashed inside.
The dash can really help to illuminate things, especially when either the blue or white fails with the contrast of a specific element. The next thing we’re going to test for is not fully obscured. We need to be able to see the focused item and be able to clearly read it. If only a small amount of the focus isn’t visible, that’s okay. But if most of the element is blocked, that’s not okay.
Make sure that if there’s a modal that covers a lot of content, that modal gets the focus. Make sure that our focus doesn’t end up off screen and make sure that other elements, such as a floating header or footer, are not obscuring it.
Here we are on a website, and I’m going to hit the tab key, and the focus is behind this large pop-up. This pop-up is covering pretty decent amount of screen real estate, and we can’t see the focus. Finally, I get a focus that’s actually visible to me. We’ll see also that a number of elements aren’t even focused in the first place. This focus is also a not sufficient contrast to be visible with a 3:1 ratio.
Testing focus reaches all elements
Next up, we have focus reaches all elements that it should. If there is a visual button on the page, the keyboard focus needs to reach it. If there’s a link, the keyboard focus needs to reach it.
The common problem here is when buttons are coded as divs. Sometimes links are even coded as divs, and then they attempt to facilitate everything with JavaScript. Unfortunately, this causes accessibility issues. Semantic markup is very important for accessibility, and you shouldn’t try and fix issues caused by lack of semantic markup by just throwing more JavaScript at the problem.
Here we are back on the site, and you’ll notice that I cannot get the resources menu item to be focused. It’s just not possible.
Next, I’m on the Maryland Tax Connect website, and I am attempting to get the focus state to go to that menu icon on the left. I am at the item after it, and I cannot get the focus to go to the menu item. That element is completely unreachable.
Testing focus order
The next thing we want to do is make sure that it follows a logical visual order. For Latin-based languages, that means left to right, top to bottom.
Here we are on EZ website for New York. I can see that there is a very hard to read focus state in the top section. It has then skipped the top middle of the header. There are a couple of links there and they have been completely skipped, so that is out of visual order. That’s a failure of visual order. We go through a few more items in the top, and now we have drop down to the footer of the website.
This is going straight from the header to the footer, completely bypassing the main content of the page. This is clearly out of order.
Focus on modals and popouts
The next one is modal windows and popouts. When a modal window or a popout covers a significant amount of the screen real estate, that needs to take focus so that you can interact with it and get it dismissed and read the content behind it. Here we are on Equalize Digital, and they have a modal, and it is allowing me to go through the different elements in the modal, and I am just cycling through them. It’s keeping my focus contained within this modal, but I can use the close key and exit the modal.
Now my focus has returned to the actual website. Here I can go through and visit the various different items seeing a clear focus state. An example of the modal not being contained would be this site. Here we have, I can’t get to that modal at all. It’s a real problem because it is blocking a ton of my page content.
Focus never trapped
The next item is that our focus is never trapped. The good news is this does not happen very often. I don’t happen to have a handy example available. But what would happen would be your focus gets locked between one or two elements, and you can’t get your focus to leave those elements, pressing escape tab, shift tab, down, up, left, right. None of that actually gets you out of the area, and you’re just stuck. That’s focus being trapped, and you don’t want to see that.
Recap
To recap, when we’re testing for this keyboard focus state, we are testing to make sure that it’s visible, not fully obscured, reaches all elements that it should, goes in logical visual order, is contained from modals, and is never trapped.
Thanks for watching. I’m Gen Herres from the Easy A11y Guide, where we try to make accessibility easier to implement through done for you services, tools, and processes. If you enjoyed this video, please give it a thumbs up. It really helps our channel.
You can subscribe to our channel for more accessibility tips and to be notified when new videos are released. For more information on web accessibility, including services, tutorials, and more, please visit easyallyguide.com.
Thank you so much again for watching, and I look forward to seeing you in the next video.