2

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).

TylerH
  • 20,799
  • 66
  • 75
  • 101
G0BLiN
  • 905
  • 10
  • 18

3 Answers3

4

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"!

GrahamTheDev
  • 22,724
  • 2
  • 32
  • 64
  • Thanks for the answer - appreciate the explicit mentioning of being WCAG compliant but with a terrible user experience. Looking at the examples, though - they all seem to describe *interactive* elements - e.g. a tab section where arrow keys allow switching the active tab is functional, same goes for a navigable data table as long as there's some action to perform on the cells - even if just to change column width etc. (if it only presents the data, though, not sure if it makes sense to make it focusable at all). Did I miss something here? Could you provide a non-interactive example? – G0BLiN Mar 24 '21 at 14:39
  • Well the answer is no then, I mean it doesn't get any less interactive than a tab **panel** being in the focus order (as the panel itself is not interactive) with no focusable elements inside. You won't find anything in WCAG I don't think (you can never be sure as despite reading WCAG nearly every day there are thousands of pages so I may have missed / not remembered something) and WCAG is the best we have for official guidance. At this point I am trying to understand what you are referring to? We could obviously be silly and make a random word receive tab focus, that would be a no though! – GrahamTheDev Mar 24 '21 at 15:54
  • The only things that should receive focus in the Tab order are things that you can interact with, i.e. pressing enter or space will cause some action to occur. No item should be able to receive keyboard focus if it does not have an action except for the very rare circumstances above. [MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Keyboard) "However, you should only add tabindex if you have also made the element interactive, for example, by defining appropriate event handlers keyboard events." – GrahamTheDev Mar 24 '21 at 16:01
3

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.

Jonathan Pool
  • 369
  • 1
  • 9
  • In your first scenario that is what `tabindex="-1"` is for - you can focus the item without adding it to the focus order via JS, adding `tabindex="0"` to it would be invalid as it is a non-active element that can receive focus. If you use a hyperlink in your skip to content links then focus-visible does not apply until you press TAB, in which case the next active item should be focused. Otherwise every HTML page that uses anchors would be invalid. Not sure what you mean by the second one but that also "smells" of making something focusable as it is not implemented correctly. – GrahamTheDev Mar 30 '21 at 20:11
  • Good points, though Success Criterion 2.4.7 says keyboard, not Tab key. Pressing the Enter key to activate a skip link or dismiss a dialog is a keyboard use. – Jonathan Pool Apr 01 '21 at 02:59
2

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.

ArmandFrvr
  • 97
  • 1
  • 7