New rule: Flag elements with tabindex >= 0 without semantics that signal interactivity (Best Practice)

[0ddfell0w]

Flag elements inserted into focus order without semantics that signal interactivity.

Checks that all elements without an aria role have a tabindex value of -1. Elements without an interactive role (implicit or explicit) are unexpected in the tab order.

Tags: cat.keyboard
Impact: minor

Selector

div, span, p, and heading elements inserted into the focus order

---

Checks

keyboard/focus-order-semantics

Passes if

• element has role of type widget or composite OR
• element has a tag name that implies it might scroll¹ OR
• element has a role that implies it might scroll²

Other, generate a violation

¹ Tags for scrollable elements: article, section, nav, aside
² Roles for scrollable elements: article, complementary, contentinfo, directory, document, form, main, navigation, region

[WilcoFiers]

I don't see how this is an accessibility violation. Can you elaborate what you based this on? I've been considering something similar for element contained within role=application. Is that what you're looking for?

[0ddfell0w]

I should have been clearer and included some reference to focus/tab order in the description, adding one now.

The idea is that flat text would be unexpected within the tab order. If the flat text is somehow interactive, that should be exposed to assistive tech using an aria role. Thoughts?

Success criteria for focus order: https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html

[dylanb]

@0ddfell0w if you wanted to create a rule, it should be:

Look for all elements with tabindex >= 0 defined

1. If they do not have a widget role (implicit or explicit) and
2. they are screen reader visible

generate a violation

[marcysutton]

I think it's the naming that got me confused: "Require a tabindex value of -1 for all flat text elements without an aria role". It's more like "Flag elements with tabindex of 0 or 1+ and flat text without an ARIA role". We could potentially exempt uses inside of role="application".

[0ddfell0w]

You are both correct, will edit it accordingly

[0ddfell0w]

Updated to remove references to "text" elements, thanks @dylanb.

[WilcoFiers]

I think we need an exception for elements within a role=application element.

Furthermore, I want to have a closer look at if this is a true WCAG violation, or if this should be a best practice. I doubt it's a violation of 2.1.1. Is just having one of these on a whole page really a problem? I doubt it tbh. Now if the whole page is peppered with them you could maybe argue that it's significantly more difficult to operate the page with a keyboard then it is with the mouse. Even that is stretching the requirement quite a bit. The argument would have to be that it is impossible to use a page by keyboard if it has a lot of focusable elements that don't do anything. I don't think that that's true.

The alternative I see here is to argue for 4.1.2 (name, role, value). One might argue that if something is focusable, it should have a role. Then the argument would be that anything that's focusable is a user interface component. That interpretation makes a little more sense, but then you can't make exceptions for role=application, which I'm almost certain we will need.

In short, I don't know. I'll do a little more research and ask around a bit, see who's actually calling this out as a violation and what arguments they use.

[dylanb]

@WilcoFiers I think it should be a best practice rule TBH - I am also concerned about false positives, s o if we implement this, I'd like to see it as experimental first

[WilcoFiers]

Agreed. @0ddfell0w Can you update the rule accordingly?

[dylanb]

More thoughts:

1. This will definitely generate false positives for scrollable regions containing text, so we should exclude scrollable regions
2. Impact should be 'minor' because it causes irritation rather than inaccessibility
3. Category should be 'cat.keyboard'

[0ddfell0w]

Sorry for the verbosity, let me know if I can clarify anything.

@dylanb your point about scrollable regions is interesting. There are several non-widget roles that might appropriately imply interactivity on a scrollable region, and I would argue that such a region does need a landmark role that helps explain what it is and why it's focusable.

I've updated the description and changed the wording about widget roles to encompass other roles that might signal the interactivity of the element (including cases where the only interaction is scrolling).

There are a few options i think are reasonable, let me know what you think.

Suggestion 1: Have one blacklist of roles we know are inappropriate for elements with tabindex > -1. We would still allow landmark roles like 'region' that might be appropriate for scrollable content, but we wouldn't allow landmark roles like banner to be interactive.

Suggestion 2: Have separate rules, one for scrollable regions and one for everything else with tabindex > -1. Allow all widget and some landmark roles for scrollable regions, but only allow widget roles for other elements with tabindex > -1.

Suggestion 3: Ignore scrollable regions entirely (@dylanb's original suggestion)

Example of a scrollable region without a role: Google Docs keyboard shortcut list

With respect to the risk of false positives on scrollable regions, here's an example of a scrollable region where it's pretty clear from the label what's going on, but I still think it should have a (landmark) role.

1. https://docs.google.com/document/create
2. Use Super+/ to open keyboard shortcuts dialog
3. Tab to the scrollable region

Because there is no role on this, when a screen reader user focuses on the scrollable region they'll hear only "Group" or "Section" followed by the name of the element (which might be descriptive but might not be).

[WilcoFiers]

I don't really understand this new part:

excluding elements within scrollable regions

I think to Dylan's point, we shouldn't exclude the scrollable regions themselves, I don't think that extends to anything within a scrollable region. There's another problem to consider with regard to scrollable regions. Different regions may or may not be scrollable depending on the dimensions of the window, or even depending on the page content.

We'd need a way to know that a region might be scrollable, even if it isn't in the specific situation you're testing. Unless this best practice requires some type of markup for regions that might scroll, such as a landmark indication, this rule will undoubtably have false positives.

The alternative would be to limit the rule. We could restrict it to inline elements online. That would probably still catch most offenders without us having to deal with the scrollable regions, even potential ones.

[0ddfell0w]

You're right, changed the description from "excluding elements within scrollable regions" to "excluding elements that are scrollable regions.

I'm not sure I understand the suggestion about inline elements.

I can understand not wanting to distinguish scrollable regions from other elements, what do we think of the idea of having a blacklist of aria roles for elements with tabindex > -1? And/or recommending that all elements with tabindex > -1 must have a whitelisted role (i.e. a widget role or one of the landmark roles that could be appropriate)