Popular posts

Navigating an app is not limited to the tab key. Each screen reader and assistive tech has a set of keyboard shortcuts and gestures for accessing the details you need. The tab key navigates through clickable elements, but isn't appropriate for headers, for example.

The most important part of handling screen readers, clickable interactivity, and context, is managing your focus. It is important to understand how your clickable elements are moving a user out of the flow of the content, and where you should return them when they are finished with that section.

⚠️ Caveat: Context is very important for accessibility, so I'm going to ask some questions before I provide an answer. So that this answer still provides helpful info until you answer, I'll provide some context-less recommendations in the meantime.

Questions

• Why is the text rendered as images?
• Why does the user need to tab to these specific parts? (What action do they need to take once they tab?
• What platform is this on/using what tech?
• What testing are you conducting?

General advice

• IMHO adjusting tabindex and manipulating tab order manipulation should be something we avoid as much as possible and use as a last resort. Once you force a certain tabindex, you are overwriting the natural flow, which can make things an ordered mess. So, again, without context, here, I would want to make the text live instead and not manipulate its focusable state (as most text isn't focused in flow unless it's a link or button or something interactive like that).
• Text rendered as images should use alt-text instead of aria labels for the most part to describe its content.
• Any images that are vector can usually be rendered as SVG instead, which will allow exposing of <text> elements.
• Generally speaking when we open the can of worms of manipulating focus, tab, and trying to make non-interactive elements interactive, we are fighting against the native behaviour of elements. We will then have to fight with our technology to do what we want, and as assistive technology is very inconsistent, it's going to be difficult to test to know how it works (and if it works) for those various technologies.

It is an Articulate eLearning module. There are many issues with it, but as I work with the eLearning developers to remediate them, I want to be clear about why making non-interactive elements tabbable is inappropriate. I am assessing the modules using Accessibility Insights Tatiana Mac

Matt Kreiling Thanks for that context! Great to hear you have an accessibility checker.

I think that it would be helpful to test the module with various assistive technologies to show how the screenreader will read the information and how a keyboard will navigate it (if you're not doing that already). Most of the time, the user should not have to tab to the element in order for it to be read—and keyboards are more than tab. Focus should be reserved for when the user needs to interact with that element, like links and opening closing modules.

Generally speaking, if you're using semantic markup, the correct elements will be focusable and the reading/tab flow will be handled by going in linear order, which is expected and good. I don't use Accessibility Insights myself so I'm not sure if it has a feature that can visualise the tab order for you, which I find helpful if I ever am forced to manipulate.

I hope that helps? Happy to answer any specific questions with more context as I can.