Add notes to 2.4.3 understanding

[patrickhlauke]

Closes #1572
Closes #2655

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? #1572 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)

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

[awkawk]

I don't think that I agree with this statement. The issue is that the interpretation of the visual presentation is subjective.

[patrickhlauke]

does not necessarily need to follow visual presentation, perhaps? i've seen extreme cases where auditors gleefully fail things if they're not exactly in the same order as the visual, with things like three little icon-based buttons that receive focus right-to-left instead of left-to-right (because the author used CSS floats that effectively reversed the order) ... but where the meaning was not impacted and it was not really a problem.

there must be some way we can somehow make that clear...

[mbgower]

Yeah, add "necessarily".

[patrickhlauke]

wonder if it's too handwavy though. maybe best to expand this, or add some more words that reflect what @awkawk rightly says...that it's subjective?

[awkawk]

Who is deciding what is the visual presentation order? Shouldn't the tab order follow whatever that is decided to be?

[patrickhlauke]

or adding "as long as meaning/operation are not affected"

[patrickhlauke]

"Who is deciding what is the visual presentation order?" not sure i follow...is this rhetorical? the author/designer will work on the visual/layout, but for various reasons the focus order may be slightly different. the point is that as long as meaning/operation aren't affected (and it's...subjectively...not too haphazard jumping all over the place) it's not necessarily a failure if the focus order doesn't strictly follow the western top-to-bottom/left-to-right (in left-to-right writing cultures)

[alastc]

We'll need to come back to this, some concern over what the 'visual order' would be, theres some assumptions in there. Can we adjust to avoid that? (See the minutes.)

[patrickhlauke]

@alastc

(See the minutes.)

have they been published yet?

[patrickhlauke]

@alastc @mbgower I've now read over the minutes, but they're...cryptic. not quite sure how to proceed here. bone of contention seems to be a disagreement around the "focus order doesn't necessarily need to match the visual order". would it be clearer if it said "visual layout" ?

basically, I contend that if you have, say, three buttons on the page, and they receive focus right-to-left instead of left-to-right, but meaning/operation is unaffected by this, then that's kosher. i've seen too many auditors fail this sort of scenario under the "in western culture we go left to right, so your buttons are wrong" guise...which I would strongly push back against (depending on scenario here of course) as nobody's really affected by this sort of thing (again, depends on the exact layout we're talking about) and it's only busy-work to file this as a hard failure of the SC.

and yes, bigger cases/examples, visually a navigation sidebar on the left, but it receives focus after all the main content. i remember this used to be one of those arguments back in the day, with people on both sides claiming "it's better for the user if nav comes first" / "it's better for the user if it comes last", both with the same sense of entitled authority when making that claim...

best practice sure, follow top-to-bottom/left-to-right (for cultures using that reading convention), but not failing sites where the focus order diverges, but still makes sense/meaning is not lost because of it.

[awkawk]

@patrickhlauke part of the discussion was that this specific part of the fix doesn't seem to be related to the issues that were raised, which was about non-interactive items in the tab order. There was discussion that there was an additional issue that was related, but no one knew what it was.

[patrickhlauke]

@awkawk

part of the discussion was that this specific part of the fix doesn't seem to be related to the issues that were raised

quite possibly, but since I was already working on the 2.4.3 understanding, I opted to also add wording to cover that aspect (which I encounter constantly in discussions) without first filing an issue.

so what's the idea? make this only about the two issues, and then file another issue for this other aspect and wait another (looks at the timestamp on this PR... Feb 2021...) 3.5 years until we get around to addressing THAT?

[patrickhlauke]

digging through the issue, I believe that originally (back in Feb 2021) the PR was more focused on just those two referenced issues. as we started wordsmithing and expanding things here, the additional more general "doesn't necessarily have to match layout" part came in as well (around the time of #1643 (comment) perhaps)

[awkawk]

Suggestions for the PR:
Lines 56-64 suggestion:
Focus order needs to allow the user to navigate focusable elements in a logical order, and that order needs to preserve any meaning or operation that the page is conveying. For instance, focus order is often considered to generally run left-to-right on sites with left-to-right text, but that is subject to the specific situation. For example, a video player with a row of button controls along the bottom of the player could implement a tab sequence that is left-to-right, but there might also be an important control such as a play/pause control which is visually centered and precedes the other controls in the tab order. In this case, meaning and operation are not affected, so it is not a failure if elements in the right-hand column receive focus first. As a best practice, though, make sure the focus order reinforces the reading order.

Line 70-76: I agree with the text content, but I’m not sure about the example. I am certainly not going to advocate for links in buttons (or the inverse) but I’m also not sure how to rationalize failing it. The strongest argument is that users may focus an item that can’t be actioned by the user, but of course that is what we are allowing with the setting of focus on non-interactive elements also… I think that we need a different example.

Line 86:
This addition on line 86 is covered by the bullet items before it and after it: “Focus order does not necessarily need to follow visual presentation or layout.” I think that we can remove it.

[patrickhlauke]

Made a few tweaks/changes to try and disambiguate things a bit more:

• while @awkawk's example of video player controls is an interesting one, I do quite like the two-column layout example as well. As the original example was a bit muddled, I tried to write it out a bit more explicitly (removing the confusing "across lines" part). we could add a further example here for cases like the video player buttons, but then it feels like we're probably overloading that one paragraph and get more into "this needs a whole new section, ideally with diagrams" territory, which I don't mind doing, but not before we get some agreement that that's what we want to do
• the "nested focusable elements where only one is actionable" example is still a good one I feel. I added the more subjective "too many" to the best practice sentence to try and square the circle of telling authors that yes, it's ok if non-interactive elements receive focus, just don't overdo it
• in the "For clarity" bullet list, I removed the "only when navigation sequences affect meaning and operability" part on the first bullet as it seems like a meaningless truism "make sure elements receive focus in an order that preserves meaning/operability only in situations where the focus order affects meaning/operability". well duh. Also remove the bullet "In those cases where it is required, there may be more than one order that will preserve meaning and operability" as, unless I'm missing something, this makes no sense? and I think it's covered better by the following bullet again about multiple orders"

[mbgower]

@patrickhlauke

while @awkawk's example of video player controls is an interesting one, I do quite like the two-column layout example as well. As the original example was a bit muddled, I tried to write it out a bit more explicitly (removing the confusing "across lines" part).

A bit more explanation of what I heard in the discussion. There was some confusion over the lack of division between reading order and focus order, and the 2-column example seemed to enforce that.
One idea I had... If you made that 2-column example more precise, it might help. So, how about talk about a page with a left navigation layout where, instead of the focus moving through the items in the left nav and then proceeding to the main content, the focus goes across by line, so that the focus jumps between the left nav and a link that happens to fall on the same line in the main content.

[patrickhlauke]

@mbgower

instead of the focus moving through the items in the left nav and then proceeding to the main content, the focus goes across by line, so that the focus jumps between the left nav and a link that happens to fall on the same line in the main content.

that would be a clear failure. my point was that there are cases where it's fine to go right-hand column first, the left-hand column. for instance, left-hand is navigation, right-hand is content, but the author decided that focus goes through the content first, and THEN the navigation. would that example work?

[patrickhlauke]

it would be nice to get this considered at some point ...

[alastc]

The TF was generally approving of this PR, just thought the sentences on lines 79-82 could do with a little tweak, @giacomo-petri will have a go.

[giacomo-petri]

During my work on the "little tweak," I've come to realize that I have more concerns than initially anticipated.

In my perspective, the current proposal's allowance for including static elements in the tab sequence is overly permissive, leading to subjective judgments. For example, if we envision a scenario with a thousand sibling nodes on a page, each assigned a tabindex="0" attribute, the proposal views this as a best practice rather than a violation of WCAG.
Discussions within the Silver WG have revolved around this topic, addressing user needs such as:

• As a user of a keyboard, I should be able to complete actions in a comparable amount of time to other users.
• As a user of a keyboard, the complexity and number of input commands required to complete a task should be comparable with those of a user of other methods of input.

Considering that the normative area of SC 2.4.3 emphasizes how "navigation sequences affect meaning or operation," it's important to recognize that making static elements tabbable also impacts meaning and operation. This is because reliance on focusability to ascertain operability becomes compromised. Indeed, encountering tabbable elements that are inoperable depending on context can be frustrating for users.

Take, for example, this image displaying a collection of static logos:

• By using a mouse and hovering over these elements, it's apparent they are not operable.
• When navigating with a keyboard and skipping past them during tabbing, their inoperability becomes evident.

Yet, if the author makes these elements tabbable, keyboard users could mistakenly presume they are functional.
This circumstance raises questions about whether confusion is being generated or not, since it's not fully covered by examples.

The web is replete with such scenarios. Consider another instance: non-operable cards showcasing various sizes of luggage below:

While we might concur that the layout is suboptimal, if these elements were made "tabbable", keyboard users would undoubtedly anticipate being able to interact with them.

Rather than solely highlighting failing examples and deeming everything else as passing, it could be beneficial to adopt the opposite approach by explaining when having a focusable, tabbable element in the tab order is deemed acceptable. Alternatively, including both successful and unsuccessful examples, with a focus on the circumstances under which adding a static element to the tab order could be advantageous, and conversely, when it should be considered a failure, could provide a more comprehensive understanding. Additionally, integrating visual examples with explanations may further enhance comprehension.

Lastly, it's common to observe developers adding tabindex="0" because they've noted that "while using a screen reader, I'm unable to audibly perceive it while tabbing."

I firmly believe that maintaining a robust and consistent method for presenting elements is advantageous for all users.
Therefore, I advocate for limiting tabbing accessibility to only user interface components, with the reasonable exceptions mentioned within the issue comments such as:

• The author facilitates users to bypass a set of operable controls and move directly to the next area, such as newly activated tab panel content accessed via a tab within a tab list.
• The author enables users to focus on a scrollable container that exclusively contains static elements.
• The author allows users to focus on crucial instructions within a form, ensuring that screen reader users navigating the page in "forms mode" can readily access these instructions.
• The author allows users to tab through a toolbar container, facilitating navigation of elements using arrow keys.

Note: Upon revisiting my feedback and examining the current proposal last time, I've read it from a different perspective (concerned that I might have misunderstood the concept entirely) regarding the term "focusable." As outlined in the issue description, the aim is to address "focusable and tabbable" elements, yet the proposal only references "focusable." It's important to clarify that being focusable does not automatically mean inclusion in the tab order. Nevertheless, I believe it could be valuable to allocate some words to clarify the intent within the proposal, particularly for individuals who may not have access to the issue history.
Indeed, understanding the proposal with "focusable" referring to elements that can receive focus but not necessarily be tabbable holds a distinct meaning compared to "focusable and included in the tab order."

[patrickhlauke]

In my perspective, the current proposal's allowance for including static elements in the tab sequence is overly permissive, leading to subjective judgments.

explaining when having a focusable, tabbable element in the tab order is deemed acceptable

then we want to make damned sure we cover all possible acceptable cases, because otherwise by implication we're saying that anything not covered there will automatically FAIL the criterion

It's important to clarify that being focusable does not automatically mean inclusion in the tab order.

in terms of focusable and receiving programmatic focus, I would hope that you're at least suggesting that it's kosher to set programmatic focus anywhere the author deems necessary, at least