Add notes to 2.4.3 understanding to try and address static content receiving focus and what does/doesn't constitute a focus order failure

[patrickhlauke]

Closes #4634
Closes #2655
Closes #1001

In short, this touches on aspects of focus order that have always been a bit... "sketchy"/handwaved:

• static/non-interactive content receiving focus (addresses Static content in tab order - failure of 2.4.3 or not? #4634 and 2.4.3 focus order with non interactive element with tabindex="0" #2655)
• focus doesn't necessarily need to follow visual layout (as long as this doesn't affect meaning/break any hierarchy/relationship implied by the layout) (no related issue for this, but as I was already proposing updates to 2.4.3 understanding, added this constant doubt/bugbear here)

Deploy preview for Understanding SC 2.4.3 Focus Order and diff.

[mbgower]

I'm a lot more concerned with redundant focus stops (i.e., press Tab and the focus does not appear to move) than I am on, say, focus moving to a non-interactive element. To the point where I'm a little concerned with this: "Redundant focus stops...are allowed..." If something is truly redundant, as in there is no change in focus (which is different than a link within a card you mention, IMO), I think that should not pass.

Whereas, there are several situations where it may be necessary to put focus on a non-interactive component. Some may be needed to put the reading order there (think of a 'go to top' button), even a skip to main may require that (focus goes to region, for example). Think of a tablist; you want to put focus in a tab panel to allow screen reader consumption, even though there is no operable control in the tab panel.. The same thing can happen on a modal overlay in which nothing is operational (strictly informational). If focus isn't placed there, it may prevent a keyboard user from scrolling up and down in the content.

So while I'm happy with almost all these changes, I would like to take out that explicit "it's okay" for redundant tab stops, but leave it in for non-operable elements.

[patrickhlauke]

I'm a lot more concerned with redundant focus stops (i.e., press Tab and the focus does not appear to move) [...] If something is truly redundant, as in there is no change in focus (which is different than a link within a card you mention, IMO), I think that should not pass.

Not sure I follow what you mean exactly. Assuming it's something like it appears not to change, but practically does? Something silly like

<div tabindex="0"><button>Test</button></div>

perhaps?

Would you say those fail 2.4.3 (I'd say generally they don't, but opinions may be split here)? And If so, how would you disallow this sort of thing / define it in a way that still allows for the non-problematic cases (card that contains a link)? That would probably require some hard definition of "redundant" (versus, say, "superfluous" or "unnecessary" or similar vague concepts)

[patrickhlauke]

Even removing the wording around redundant, wouldn't something like

<div tabindex="0"><button>Test</button></div>

still not be understood as ok based on the rest of the note as well, based on the loose wording of

Normatively, it is not a failure of this success criterion if static/non-interactive content
receives focus. Making an element that does not act as an actionable user interface component
focusable, or programmatically moving focus to such an element, does not necessarily constitute
a failure of this success criterion.

[mbgower]

I think the example you provide of a div with a tabindex surrounding a button should be considered a failure of 2.4.3:

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. (Level A)

It's not a serious error, but it is confusing and disruptive to press a tab and have nothing happen. If I was testing a page and 2 tabstops occur on the same item, I'd ask that to be remediated, and if the answer came back "it's intentional", we'd be having a discussion on why.

if we start putting language in saying such redundancy is 'okay', I think we need to be specific about what contexts it is okay. In the tile/link on tile example, if I understand what you are saying, two different focus indicators take place. Visually the focus has progressed as the user presses tab. So I wouldn't consider that a failure here. (I've seen examples where activating both may result in the same action, which I wouldn't call great design, but I think is orthogonal to Focus Order).

[detlevhfischer]

static content: "does not necessarily constitute a failure" and then: "These situations are only failures if they significantly impede the operation of the content". With focus stops on static content (e.g. all explanatory texts in a form) is remains a judgment call at what point this becomes a significant impediment. Which I believe is unavoidable - I'd call it not a "subjective" but a "context-dependent" aspect of conformance evaluation.
Would a few negative examples help to clarify what cases would be seen to fall under "significantly impede" and in turn, be cases to FAIL?

[patrickhlauke]

I'd call it not a "subjective" but a "context-dependent" aspect of conformance evaluation.

Oh, I like that, @detlevhfischer

I was actually just about to have another go/tweak on this PR to possibly remove the explicit mention of "redundant" as it may have too much baggage/implication, as @mbgower pointed out above.

I'd be all for more examples that clarify, but wonder if we'll be able to reach some kind of consensus (and make them representative enough, with enough context, to make it clear)

[alastc]

Historically we've been quite strict on redundant tab-stops, on the basis that stopping twice on the same thing is confusing because you expect to go to the next thing. A common (ish) example is a listing on an ecommerce site and you stop once on each item which isn't active, press tab again and find the active tab-stop.

It fits in with failing invisible/off-screen items under focus-visible.

I'm not sure where I'd drawn the line if you had a couple of instances vs 20?

[mbgower]

I'm not sure where I'd drawn the line if you had a couple of instances vs 20?

I would argue that "a couple" is a still a failure of Focus Order -- it is just the degree of impact/severity that is affected. If I press on the same item many times with no apparent change in focus, that is more severe; some users will just abandon the site. If I have to press Tab twice on every single item to advance it, that is more severe, due to time on task, etc.
If it happens once on the page, it may just be confusing -- especially if the user just presses again. But the user has NO idea if something important was intended to happen and it didn't. "the navigation sequences affect meaning or operation"

[detlevhfischer]

But the user has NO idea if something important was intended to happen and it didn't.

@mbgower I would argue that (most?) screen reader users will have a good idea since if it is just a p with tabindex="0" they won't get an interactive role like link or button exposed. So I feel it would be overly strict to fail content on 2.4.3 for a couple of tab stops on non-interactive content. If we are unable to apply tolerances for minor issues, we set the bar too high, iMO.

[patrickhlauke]

I've removed the explicit mention of "redundant" in this PR

[bruce-usab]

+1 to discussion as it stands. I am not disagreeing with anything, but I am taking the liberty to add one more anecdote.

Adding tab stops to static content (in particular, instructions on forms) is something that mindful developers sometimes do on purpose (SSA is one example I think). I would not like for us to to come down hard on the practice. I agree with the updated note on this thread not to be permissive with redundant stops, as those can be very disorienting.

[mbgower]

I believe the current wording in the PR is valid, and am moving this PR to "Drafted".

There are a number of points raised in this thread which cannot be addressed with the normative wording of WCAG 2. They may be possible considerations for WCAG 3.0.

didn't actually leave a review...

[bruce-usab]

Mentioned on TF call 9/19/2025.

[patrickhlauke]

there's been recent activity on #4634 (comment)

[patrickhlauke]

Note recent additional discussion happened on #4634