screen reader – Nat Tarnoff

It’s been a busy week in my house, so I’m going to keep this quick. One of the issues I often see flagged by other accessibility testers is that something doesn’t work with keyboard navigation. The vast majority of times I revisit these, it turns out the tester doesn’t fully understand how screen readers work. I want to highlight a few items for folks.

Modes

Screen readers typically have 3 main modes. The virtual browser, forms, and application.

Virtual Browser

The virtual browser is when the screen reader technology is intercepting the keyboard input and uses that to execute a function in the browser for you. When we press tab we jump to the next active item. Pressing the down arrow will read the next line, chunk, or set number of characters in a paragraph. Here’s a short list of common commands:

H: moves through the headings on the page
T: moves through the tables on the page
Control+Alt+Arrow: Move from one table cell to the next in the direction of the arrow
L: moves through the lists

Forms

When a user encounters a form element, the screen reader should automatically shift to the forms mode. There usually is ab audible sound to indicate this. This mode moves the screen reader out of the way to interact directly with the page via the keyboard. This limits how to navigate to using only the Tab and Shift keys to move among the active elements in the form.

Application

In this mode you need to have the role=”application” and then the screen reader again gets out of the way of the keyboard. However, even if you use active controls navigating between them is completely up to the author. They will work with Space & Enter to activate, but the author really needs to define the navigation scheme and controls to use the tool.

Don’t flag an issue for not being keyboard accessible with a screen reader on unless you can identify it is an application or is also not accessible without the screen reader.

There’s way more to this, but the great folks over at Tetralogical have a great screen reader misconceptions article and a full break down of commands.

Comments closed

Admiral Ackbar is letting us know something important. When we navigate by keyboard, we need to make certain of one thing. Make sure that a user doesn’t get trapped with no where to go.

This seems really simple, but it gets complicated quickly. And I know what seems simple to one person is traumatically difficult for another. Let’s talk about what a trap is, some examples, and ways to prevent them.

What is a keyboard trap?

A keyboard trap is any control that receives focus, but does not release it. Usually, the keyboard is trapped from moving in any direction. Sometimes it may be trapped in one direction, generally forward.

I’ve encountered some that prevent moving forward, but allow moving backward. Usually this presents a workaround, but not always. Even if there is a word around, it is still a violation.

Often developers will put a “forward” action on an input when the content meets a certain regex or pattern. This is difficult because the input is saying, “If I have 5 numbers, tab to the next control.” This becomes a keyboard trap as the keyboard only user cannot tab back into the field to correct it.

More common though is a disclosure control that isn’t following the <h3><button>Title</button><h3> pattern. Often the button is somewhere else or outside the heading. When the control is in focus, nothing happens.

How do we test?

If you do not need a screen reader to understand the screen, turn it off. If you require a screen reader, put it in forms mode. Forms mode will only respond to Tabbing and form control with the default keys. We don’t want interference from the AT.

Tab. Again. Shift tab. Keep using tab to navigate through the page, and do it in reverse. If you get stuck, try using the Escape key. Did that get you out? if yes, did it push you backwards or forwards?

If you find you can escape the trap, try repeating the situation in both directions multiple times. If you got out, this belongs in usability advice. If you can’t get out or can’t move in both directions, you have a violation.

What is the cause?

In most cases of keyboard traps, the cause is going to be JavaScript. Typically there is a function tied to the field being focused or activated. This can cause a race condition freezing the browser. More likely, there is function that prevents tabbing out, or the function tied to moving out is not firing.

Take the object where the keyboard trap is happening. Reproduce it locally, then start stripping back all that is tied to it. For example, if you are using custom dropdown, remove all the custom code. Begin with the base HTML <select> and <option> elements.

Is there still a keyboard trap? If you extracted all JS hooks and custom HTML, there should be no trap. Once we establish that the basic HTML works, let’s expose the custom HTML.

Hide any classes tied to JS functions. Remove data attributes. Get the JS out of the way. And try it again. Is it stuck now? Then it is time to examine out HTML again. No, then we slowly start adding in JS one item at a time until we find out trap.

Time to fix it

I cannot really tell you how long to remediate this would be. Everyone’s architecture is different and will cause different problems in different ways. But finding the trap’s location might take a day. Determining the cause could also take time, even for the most skilled developer. I recall early on spending 10 hours searching for an error in my code. It turned out to be the dreaded missing semicolon. It happens to all of us. Its about how do we fix it once we know of it.

Have questions? Come talk to me on LinkedIn or BlueSky!

2 Comments

Tag: screen reader

Quick Tip: Use More Than Tab in Screen Readers