2.4.7 as it applies to static content and programmatic focus

[mfairchild365]

Apologies if this has been answered elsewhere already. I'm struggling to find an agreed-upon answer.

There are some situations where authors decide to send focus to static content via JS (think tabindex="-1" and .focus(). By default, browsers render a visual focus outline around these static elements when they receive focus. However, many authors remove this visual focus indicator for static elements and leave them for interactive elements. I find that authors do this because elements with tabindex="-1" receive focus on click and programmatically.

Some examples include:

1. When submitting a form, focus is sent to the container of an error message above the form.
2. In a single page application, a routing event automatically focuses the heading at the top of new content. I put together an example of this to illustrate SPA link routing.

The normative text of 2.4.7 states

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

The informative text of the understanding document suggests that this is to help "anyone who relies on the keyboard", and users with "attention limitations, short term memory limitations, or limitations in executive processes" 1. understand exactly where focus is on the page at all times, so that, 2. they can predict what will happen when they issue a keyboard command.

Do these situations require a visible focus indicator to meet 2.4.7?

One read is 'yes', since, without it, 1. users may not know exactly where focus is at all times, and 2. users may not be able to predict what will happen when they issue a keyboard command.

Another read is 'no' since the static element itself is not keyboard operable in of itself.

[JAWS-test]

I think that in this case (automatic focus on static content) the WCAG does not require focus visibility.
With the next tab step, the focus becomes visible. But I would still recommend displaying the focus on static content, because it makes orientation easier.

[patrickhlauke]

It's not a hard failure, and there are situations that even without suppression, browsers don't ALWAYS show current (reading) focus by default - for instance, when loading a page, following an in-page anchor, etc. Even without any intervention on the part of authors, browsers don't show where the reading focus moved to. But yes, there will be situations where authors should strongly consider showing focus when it's moved programmatically to a static part of the page if it avoids user confusion.

[mfairchild365]

Thank you, those are some good points @patrickhlauke. While I agree that it shouldn't be a hard failure, I'm struggling to see where the normative text of the SC allows for it to be hidden. Am I missing something? If nothing else, perhaps there is room to clarify this in the understanding document.

[patrickhlauke]

normatively, the SC applies to "any keyboard operable user interface". if focus is programmatically moved to static text, that text is not a "keyboard operable user interface" per se (as it's not operable/interactive, it does nothing). the understanding document does focus on interface components like buttons, text edit fields, etc. but yes perhaps making it clear that static, non-interactive/non-operable elements that receive focus do not necessarily need to have an explicitly visible focus indicator.

[JAWS-test]

Even though the WCAG does not require focus visibility on non-interactive elements, I would not like to see this in the Understanding because I see this as a shortcoming of the WCAG and from an accessibility point of view the focus should always be visible when navigating with the tab key. The initial question was whether the focus should be visible for static content that is focused via JS - and only in this special case I would say that it is not a relevant accessibility issue

[patrickhlauke]

it may be a shortcoming of WCAG, but NOT making it clear helps nobody and just leaves this ambiguous. a shortcoming of WCAG should be flagged clearly, and if need be addressed with another new SC, not swept under the rug.

[mfairchild365]

@patrickhlauke thank you for the clarification. That helps my understanding. I think this boils down to how "keyboard operable user interface" is defined by WCAG.

Does this mean

1. An interface which includes at least one keyboard operable element OR
2. only parts of the user interface which meet the definition of "user interface component" and are keyboard operable

In other words, I had assumed that the "keyboard operable user interface" referred to the entire interface, not just specific components within the interface. Now, normally, static elements within the larger interface never receive keyboard focus, however when they do (for example as the result of programmatically sending keyboard focus), "the keyboard focus indicator is visible".

[JAWS-test]

The Understanding speaks of "keyboard actionable control" that receive the focus, but in the failures (and techniques) there it is sometimes about of all elements that receive the focus, e.g. in F78:

1. Set the focus to all focusable elements on a page using the keyboard.
2. Check that the focus indicator is visible.

However, the SC does not require focus visibility for the operable elements, but for all elements that receive the focus (if there is more than one such element)

Since only the SC is relevant as a normative text, the Understanding would need to be adapted: The focus must be visible on all elements that can receive the focus when the user operates with the keyboard. No focus visibility is required when focus is set via JS.

[alastc]

I think this is the key aspect:

if focus is programmatically moved to static text, that text is not a "keyboard operable user interface" per se (as it's not operable/interactive, it does nothing).

Noting that there will be updates to 2.4.7 as part of WCAG 2.2 (latest understanding text), I think adding something to the first line such as:

The purpose of this success criterion is to help a person know which keyboard operable element has the focus.

I agree that in some scenarios the lack of focus indicator on static text could be confusing, but before adding such a requirement we would want to be sure of the impact. Folks on screenreaders going through the content have a slightly different use-case to people tabbing through visually, and I don't want to setup a confict.

For example, aren't there scenarios where you'd want to move focus into a model dialogue but not have an explicit focus indicator?

[patrickhlauke]

i'd say the understanding doc should quite explicitly add a note saying that in certain situations, focus may move to non-operable/static content (as is the case when a new page is loaded - focus is reset to the start of the document, but there's no visible indication at all until user moves to the first actual focusable operable control; similarly with in-page links to named anchors/fragment identifiers; or, even programmatically, the content area/container for content-based dialogs, as @alastc noted). i'd leave it at that, that the SC normatively does NOT require visible focus indication in all scenarios, but only when keyboard-operable controls receive focus...but then as a best practice, authors are encouraged - if appropriate - to provide visible focus indication where deemed necessary even if it lands on static content, as long as this doesn't end up confusing sighted users.

[patrickhlauke]

incidentally, if static content has been incorrectly forced to receive focus via tabindex="0" or higher (i.e. it's in the tab cycle, but doesn't actually do anything...i often see this in misguided attempts to "make sure screen reader users can get to the text" by clueless but well-meaning devs who don't know how real AT users actually navigate pages), and THEN focus is not visible, i do think it's a failure of both 2.4.7 AND 2.4.3 (though it can be argued here whether or not this is a loose interpretation of 2.4.3). reason here for failing 2.4.7 to me is that the author has, by virtue of adding tabindex="0", turned the content into a keyboard-operable (or at least keyboard-focusable) element, and thus 2.4.7 now applies. of course, the remediation here would then be NOT to force the static content into the tab focus cycle, which then removes the failure for both 2.4.3 and 2.4.7.

[awkawk]

I think that this is pretty straightforward - if the keyboard focus is set on anything, whether it is actually interactive or not, then the keyboard focus indicator needs to be visible. It is a separate question about what the user can do at that keyboard focus location, and if the answer is that they can't do anything then that seems to be a lousy experience but that aspect doesn't result in any normative failure.

This seems to be in agreement with what @patrickhlauke said above, although I wouldn't say that it is necessarily a 2.4.3 failure unless separately evaluated to fail.