Is it ever a good practice to make non-functional elements keyboard focusable?

Question

WCAG's definition of functionality

processes and outcomes achievable through user action

link to source

Following WCAG's definition for "functionality", it seems intuitive that just as functional elements should always be keyboard focusable, non-functional elements should not. However, in accessibility matter, naïve intuition can be misleading. As I could not find any definitive guidelines or failure criteria for this on W3C site, I'm asking here:

Is it ever a good practice to make a non-functional element keyboard focusable?

If there are W3C or other official standards supporting your answer, please mention them.

---

Note 1: Please do not provide scrollable but otherwise non-interactive elements as an example - for our purpose, scrolling is an interaction.

Note 2: Somewhat related, but not a duplicate of the question "Should text ever be focusable for accessibility? I'm specifically thinking about key-value pairs", also somewhat similar to this question: "Accesibility vs. read only inputs", but that was asked in 2013, and its single answer isn't authoritative enough IMO (and I'm guessing is incorrect for today's accessibility conventions).

Answer 1

I've seen a few error dialogs implemented this way, where the only interactive element on the dialog was the OK button, and they decided to set tabindex="0" on the message text. This meant they could put focus on the OK button when the dialog opened, for faster dismissal, yet allow screen reader users to tab to the message text. This was probably more common before we had role="dialog". Overall I would say that making a noninteractive element focusable should be situational and rare. Don't do anything that would confuse users. But if it results in something that's intuitive and easier to use, I would say go for it.

Answer 2

If you adopt the principle that the focus should always be visible, then situations can exist in which the only way to make that be true is to put a non-interactive element into focus. A skip-navigation link needs a destination after the navigation header, but it is possible that nothing in the main region is interactive. A modal dialog, when dismissed, needs to have a focal successor, but its dismissal may cause the triggering element to disappear and leave no other element, or at least no intuitively reasonable successor element, interactive.

Another scenario: A user action could cause informative messages (hints, clues, annotations, etc.) to be inserted at various points throught a view. They might all be in live regions, but that would not make them easy to locate. Making them focusable would allow the user to navigate through them sequentially, ensuring that none of them is missed and no laborious searching is required.

Answer 3

Is it ever a good practice to make a non-functional element keyboard focusable?

Yes, but in very rare circumstances.

Oh, you want a longer answer? 😋

Tab panels are a prime example (and the only concrete example I can think of) of when tabindex="0" is useful.

In this instance it serves no purpose other than to allow a user to easily navigate to the panel so they can read it's contents.

This is demonstrated and explained on the W3 Example of manual tab activation page.

The reason this is suggested is that it functions in a similar fashion to a "skip link".

All the tabs are operable with the arrow keys, but the whole tab list is one tab stop.

Then when a user has opened the tab they want to read they can press Tab in order to jump to the content instead of having to read out the rest of the tab options.

Some "fluffy" examples

The only other time I have seen this used and it felt correct is in a "live chat" application when you could Alt + Tab through the conversation items. This felt better than using headings, sections or other ways we may make something keyboard navigable (and arrow keys didn't feel intuitive).

One last one that comes to mind would be data tables, sometimes you may want a table to receive focus so that a user can navigate by arrow keys. So it receives focus to activate the component and let people know it is interactive via keyboard.

I am thinking of someone not using assistive tech but who uses the keyboard due to mobility impairments in this instance.

However that is just speculation I have never implemented that myself and if I did it would probably be because a highlighted row changes a graph etc. (which I am sure you would count as interactive!)

Any official guidance?

With regards to official guidance, I doubt you will find something concrete. Obviously WCAG 2.4.3 - Focus Order does come into play here as adding a tabindex="0" to everything is not a "logical focus order", but it will not give you a definitive answer as it has to allow for custom components etc.

I am afraid this one is a "best practices" rather than a rules scenario. You would probably still pass WCAG if every item on the page had a tabindex="0" as WCAG doesn't focus on user experience but rather on whether something can be used at all. However nobody who relies on assistive tech would want to use the page with a hundred tabindex="0"!