Wcag: Static content in tab order - failure of 2.4.3 or not?

[patrickhlauke]

A discussion that seems to keep bubbling up (most recently on WebAIM https://webaim.org/discussion/mail_thread?thread=10037) is whether or not static content that receives focus (e.g. because it has been marked with tabindex="0") is a failure of 2.4.3 or not.

My take for the longest time has been that, unless the order that these static elements receive focus in makes stuff illogical/affects meaning of the overall content, that this is fine. I don't think static content receiving focus violates the normative wording of the SC

If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

I also don't see anything in the understanding document that suggests anything about static content being focusable as being a failure.

To be clear, I would generally flag inappropriately focusable static content as something that a developer should address, but I make the point of clarifying that it doesn't strictly (to me at least) fail 2.4.3 (or any other SC). That it's more of a usability problem.

Long story short: it would be good to get a consensus position on this, and to add an example/clarification/note to the understanding document about this.

[patrickhlauke]

noting that there are situations where static content will generally need to be focusable, or where a user agent chooses to make it focusable. examples include static content that has a custom tooltip (where one approach is to make the static content focusable, so that the tooltip can be shown on focus), a scrollable <div> that is made focusable so keyboard users can easily scroll it, and the way Firefox makes <iframe> elements focusable by default.

[patrickhlauke]

further, i'd add that I do generally fail situations where a component/widget has redundant tab stops that make it illogical, e.g.

<a href="...">
  <span tabindex="0">Something<span>
</a>

or similar monstrosities. but in those cases, I'd say there's a nuance of illogical/nonsensical focus order at play, and THAT is what i fail (not necessarily the fact that the inner <span> there is static content).

[detlevhfischer]

Agree with @patrickhlauke that as long as the tab order is logical, just making static content focusable will not fail 2.4.3 (but be a good reason to include best practice remarks, point out the usability issue etc.). It is tempting an some cases - I had a site in audit recently where the user was forced to tab through several hundred pins on a map to advance beyond it. In these cases, there may be other SCs that are more applicable for failing content ( in the case of the map, it was 2.4.1 Bypass blocks).

[awkawk]

The concern that I usually raise with teams is when items receive focus but there is no further opportunity for interaction. A screen reader user will hear whether the focusable item is a button/input/link but a sighted keyboard user will need to try to hit enter or space (for me usually resulting in the scrolling of the whole page) to determine if the item is focused for some reason.

I would not agree that it is a 2.4.3 issue, for the reasons @patrickhlauke indicated, but I do think that this is moderately problematic. A keyboard user can readily recover from this, so it seems that the time where it is really a problem relate to a large volume of unnecessarily focusable items.

[mraccess77]

I agree with Patrick and Andrew, there are situations pointed out where elements may not appear interactive but need to be in the focus order. Having a piece of static text such as an error message in the focus order while not correct is likely not a strict fail of WCAG. However, having a large number of non-interactive elements in the focus order is likely to be problematic and would be something to be address under a WCAG audit. This is a good example of what WCAG 2.x is not good at and what I hope WCAG 3.0 will help with.

[patrickhlauke]

ok, i'll see if i can get the ball rolling on a note/addition to the understanding doc (noting that while this sort of thing may not be a nominal failure, authors should still strive to minimize unnecessary/non-interactive focus stops as a matter of usability/best practice, possibly even with a cross-reference to bypass blocks SC)

[alastc]

Generally agree with the comments above, there does seem to be a gap in the guidelines for 'excessive' tab-stops on non-interactive content, given that it's hard to define "excessive".
(Gap because 2.4.3 is scoped to 'focusable components', and link-purpose is scoped to links, so the lack of purpose/label for a non-link isn't in scope.)

We do sometimes fail this where it is particularly confusing, e.g. having a double tab-stop for 1 item, in a list of items, but in general it's hard to fail things like every paragraph being a tab-stop.

Adding 'wcag.next' label so it comes up for Silver later.

[patrickhlauke]

based on what appears to be consensus above, i'll propose a small addition to 2.4.3 understanding to that effect (that, in short, it's not a normative failure, unless it creates an illogical focus order - such as double/redundant focus on elements/widgets - but that it nonetheless can cause a usability issue and as best practice should be avoided)