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)

[mbgower]

I put in a comment in the PR @patrickhlauke I would caution about language specifically allowing redundant tab stops. I'd prefer to keep that out, but otherwise, think the changes are an improvement.

[stevefaulkner]

Is there language in there about each focusable element requiring a visible focus indicator?

[patrickhlauke]

@stevefaulkner that would be a separate concern for 2.4.7 Focus Visible, not something that 2.4.3 Focus Order should address, no?

[patrickhlauke]

I put in a comment in the PR @patrickhlauke I would caution about language specifically allowing redundant tab stops. I'd prefer to keep that out, but otherwise, think the changes are an improvement.

commented on the PR https://github.com/w3c/wcag/pull/1643 as well, but putting an abridged version here too: it probably comes down to how you'd define "redundant" in a way that is unambiguous. and even removing the wording specifically about "redundant" tab stops, you could infer they're covered already anyway by the more general "it's ok if static content receives focus"? or maybe i'm missing the specific problematic cases you mean

[mbgower]

it probably comes down to how you'd define "redundant" in a way that is unambiguous. and even removing the wording specifically about "redundant" tab stops, you could infer they're covered already anyway by the more general "it's ok if static content receives focus"? or maybe i'm missing the specific problematic cases you mean

What I meant by redundant was: same item effectively has 2 tab stops; no visual difference either in what has focus or the focus appearance.

[patrickhlauke]

it'll come down to defining "same item" though, because it'll still be two separate elements that receive focus. and what if the "outer" element that receives focus has a focus appearance that's slightly different/offset from the focus apperance of the "inner" element?

[patrickhlauke]

maybe needs to lean on the slightly squishy concept of user interface control (since we had those discussions about what "really" gets focus and what "appears" to be the control in that focus appearance discussion not so long ago). and maybe coming right out and saying that "redundant" is fine (or if we can find a better term, even better), but that the same UI control having two or more focus stops is a problem? though then it can still lead to questions about whether a card component where, say, both the image and headline are focusable separately would fail or not (they shouldn't really, as long as the order is correct)

[mbgower]

I wasn't trying to propose "same item" as language. I'm just saying that I don't think we should explicitly put something in the Understanding document saying an author can have a "redundant tab stop" and it passes this SC.

what if the "outer" element that receives focus has a focus appearance that's slightly different/offset from the focus apperance of the "inner" element?

Focus Order is to a degree about perception, since for sighted users (if not using a supplemental AT) the focus order is established visually. Where the user can see there is a change in what has focus, I think that suffices (regardless of degree of change). It may still be a poor user experience -- and I think some testers may fail some such things and point to this SC as grounds. Where there is no visual difference after a user presses Tab, there is clearly a point of user confusion.

So to me, if we are going to try to clarify interpretation of an existing SC, we need to be extremely judicious.

Here is what you wrote:

Similarly, redundant focusable elements – for instance, having two or more "focus stops" for what may visually appear to be a single user interface component such as a "card" component – do not automatically fail this criterion.

These situations are only failures if they significantly impede the operation of the content, or create illogical focus orders - for example, a control appearing to receive focus multiple times due to the use of nested focusable elements.

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

As a best practice, authors should avoid excessive use of focusable elements which cannot be operated or actioned, as well as redundant focus stops, as these are likely to make operation unnecessarily tedious for keyboard users.

I'd have less of a concern if some changes occurred.

Similarly, although redundant focusable elements do not automatically fail this criterion, these situations are failures where they impede the operation of the content, or create illogical focus orders - for example, a control appearing to receive focus multiple times due to the use of nested focusable elements.

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

Authors should avoid redundant focus stops as well as excessive use of focusable elements which cannot be operated or actioned, as these are likely to make operation confusing or inefficient for keyboard users.

[mbgower]

BTW, in a discussion we were just having at IBM, it was pointed out that we should be careful to distinguish between tabbable and focusable. You can programmatically set focus on something using tabindex="-1", but unless you are doing something truly funky, that will never be tabbable (you cannot get there by pressing Tab). As such, an item with a negative tabindex arguably doesn't seem to be in the navigation order and so not within the "navigated sequentially" language of the SC.

Our discussion was primarily rules oriented, and may not be so germane to this more general discussion. However, it may be an idea to work such nuances into the Understanding document, if it is felt it helps clarify some use cases.

[patrickhlauke]

@mbgower yup a valid point/discussion (distinction between keyboard-focusable as the user navigates, compared to programmatically focused), and possibly even relevant for 2.4.3 (as, at least for my part, I would file badly handled focus management under 2.4.3 - e.g. focus being lost/reset when activating something, opening/closing a modal dialog, etc). do you think we need something more to explicitly call this sort of thing out? explain that failure to handle focus when dynamic changes occur is also a failure of the SC? (assuming I'm not the only one who thinks this falls under the SC)

[mbgower]

at least for my part, I would file badly handled focus management under 2.4.3 - e.g. focus being lost/reset when activating something, opening/closing a modal dialog, etc do you think we need something more to explicitly call this sort of thing out?

We used to call such things 'maintaining the user's point of regard.' I'm not sure we'll get full agreement, but some examples would help ascertain that.

[bruce-usab]

There is also 3.2.1 On Focus: When any component receives focus, it does not initiate a change of context which seems like it would catch very badly handled focus management. (And you will recall we recently tweaked the 'change of context' definition.)

[patrickhlauke]

There is also 3.2.1 On Focus: When any component receives focus, it does not initiate a change of context which seems like it would catch very badly handled focus management. (And you will recall we recently tweaked the 'change of context' definition.)

not quite for the scenarios i had in mind (e.g. user activates the "Close" button on a modal, but focus is not returned back to the button that originally opened the modal and is instead lost/reset)

[patrickhlauke]

unless you mean that after the focus is moved/lost, this then creates a change in context...which I'd say is turning the meaning of 3.2.1 On Focus on its head.

[bruce-usab]

@patrickhlauke — this is difficult to parse out much more without fairly concrete example, but I think I would be very comfortable failing a page where the close button on modal was significantly disorienting for a SR user. Your instead lost/reset seems to fit that.

You observation that this seems to be turning 3.2.1 on its head is fair, but focus went somewhere. So why is not such behavior a fail against 3.2.1?

[patrickhlauke]

So why is not such behavior a fail against 3.2.1?

because (for the example of the modal being closed and focus then not being handled correctly but instead resetting) that has nothing to do with the SC: "When any user interface component receives focus, it does not initiate a change of context."

the change of context (lost focus reset to start of page) did not happen "when the close button receives focus". it happened once the button was activated.

whereas you can argue that following the activation of the close button, the order in which elements receive focus has been affected (as it's been reset incorrectly) and that affects operability (user has to now laboriously tab back through the entire page, from the start, until they reach they point there were at when the modal was opened). so i'd fail that under 2.4.3 Focus Order.

anyway, let's stay on target though. this discussion here is not about 3.2.1

[philljenkins]

I think there needs to be a distinction between "focusable" and "tabbable" in the explanations. For example, local anchors receive focus, but are not in the tab order natively by browsers. Developers should not be adding tabindex to static content that is only there as local targets, and not otherwise operable.

So tabbable elements (elements in the tab sequence) must have operable widget roles, but not all focusable elements (including static content) need to have roles.

[patrickhlauke]

So tabbable elements (elements in the tab sequence) must have operable widget roles,

suggested discussion point: lowercase must, uppercase MUST, uppercase SHOULD ? (x-ref https://github.com/w3c/wcag/issues/3029#issuecomment-1433854917)

[mraccess77]

I can imagine some situations were tabbable elements might not have a role - but 95% of the time they need to. Sometimes we have to put scrollabe regions in the tab order to allow for keyboard access - I suppose a scrollbar role added to an element could be added rather than relying on the browser default - but that seems like a lot of work for no material value.

[patrickhlauke]

@mraccess77 and I think the crux of #3029 is, in short, about those 5% of cases where an author has made something tabbable:

• is it, by virtue of being tabbable, considered a user interface component and thus subject to 4.1.2
• does it then, as a result, hard fail 4.1.2 for lack of a role

if yes to both, then this should be made explicit both in 4.1.2's understanding ("anything that's tabbable MUST have a widget role") and, related to this issue here, included as a cross-reference/clarification in the understanding for 2.4.3 proposed in https://github.com/w3c/wcag/pull/1643

[awkawk]

Are we considering failing content that is tabbable because it doesn't have a role (it does) or because AT isn't explicitly communicating the role? I agree that items that receive tab focus should be interactive, but I don't think that a span of text or a non-interactive image fails to have a programmatically determinable role. It seems that the argument for 4.1.2 applying here is if the role is sufficiently inappropriate then it isn't sufficient (like in F59: https://www.w3.org/WAI/WCAG21/Techniques/failures/F59.html) but I don't think that WCAG 2.x has enough detail to make it clear that all tabbable items must have widget roles so I wouldn't call this a failure.

[patrickhlauke]

@awkawk for what it's worth, that's been my view/take, but the IBM interpretation is stricter here it seems

[tombrunet]

@awkawk At the time that 4.1.2 was introduced, tabindex wasn't allowed on all elements (see https://www.w3.org/TR/html401/interact/forms.html#adef-tabindex). At the time, all tabbable elements implicitly had widget roles - aside from scrollable containers / frames where browser behaviors are still inconsistent. That detail was redundant with the allowable usage of tabindex at the time. 4.1.2 knew that ARIA was coming, but didn't fully know how ARIA would be implemented.

[anevins12]

I could really do with your PR https://github.com/w3c/wcag/pull/1643

[brothercake]

My apologies -- I have a ticket on the same subject in a different repo, and closed the wrong one. 🤦🤦