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.

[patrickhlauke]

This seems to be in agreement with what @patrickhlauke said above

not quite. i'd make a distinction between something that has been given tabindex="0" and thus falls in the keyboard tab cycle, versus focus being moved programmatically to something with tabindex="-1", as in the latter it's similar to situations like focus being reset to the start of the document on a new page load, jumping to a place in the document with an in-page link, etc. Those situations don't cause browsers to show focus indicators, and similarly should not require authors to provide focus indication when programmatically setting focus either.

[awkawk]

Reading @patrickhlauke's response from two back and I don't think that there should be an understanding addition that indicates that the focus only needs to be visible only when keyboard-operable controls receive focus. The need for the focus to be visible helps users know where the focus is and if it is allowed to be invisible some of the time then users will have trouble using the content.

As Patrick indicates, there are times that the focus does become invisible, such as when the page is loaded, but this is a browser feature that moves the focus to the browser window frame and is largely outside the control of an author. In this case, the focus is not shown because the focus isn't inside the page so there isn't a WCAG failure.

[awkawk]

@patrickhlauke good point on the in-page links - I'll think on that part...

[patrickhlauke]

The need for the focus to be visible helps users know where the focus is and if it is allowed to be invisible some of the time then users will have trouble using the content.

on the other hand, having a visible focus indication does also imply that the thing that is showing focus is interactive/operable. say you follow an in-page link to a fragment identifier/named anchor. i'd argue it's more confusing for the target/named anchor to then have visible focus indication (when normally it wouldn't in browsers).

similarly with opening a modal dialog for content, when focus is moved to the dialog container or the start of the text content itself. having the whole thing with a visible focus outline, even though it's not actually actionable/interactive, would cause more confusion. and it's certainly one of the things that designers won't want/will want to style away (though this could be mitigated by using :focus-visible where supported, so it would at least only show based on the browser's determination that the opening of the dialog was caused by a keyboard interaction).

[awkawk]

@patrickhlauke so for the reload or the in-page links the focus is on document.body and the browser is keeping track of the position within the document for what to tab to next or previous, yes?

In these cases, or in the case of a modal dialog (or a non-modal dialog for that matter) there is a visual indication that something is going on (page position shifts, page goes blank and reloads, dialog appears) so there is a visual indication to users that something is going on. What I'd like to avoid is the user not having any of these clues to set expectations of where the focus is and having the focus disappear.

I think that authors setting focus on text or an image are doing something non-standard and in most cases probably don't have a good reason, but I don't think that we want to provide an exception for that any more than we want to have a non-actionable keyboard focus confusing people.

[patrickhlauke]

I think that authors setting focus on text or an image are doing something non-standard and in most cases probably don't have a good reason, but I don't think that we want to provide an exception for that any more than we want to have a non-actionable keyboard focus confusing people.

focus is often moved programmatically to ensure that AT read something out (and to provide a new logical starting point for continued reading/focus). see for instance the example in the thread starter about error message at the top of a form after a failed submission. saying that authors don't have a good reason is perhaps a bit of a generalisation (and going with that assumption will only lead to frustration for authors who DO have a good reason and then end up having to find loopholes/justifications for why they don't just follow a blanket "everything that receives focus must show a visible indicator even when it's not actually interactive/operable")

[alastc]

If the keyboard focus is set on anything, whether it is actually interactive or not, then the keyboard focus indicator needs to be visible.

I've often created (or recommended) skip to content links which go to the <main> (or other large block), and providing a focus indicator on that does not seem helpful, and generally gets push-back from designers/product owners (especially as clicking anywhere in the block triggers the indicator). My site is an example.

Focusing on the first interactive element would skip important content for those using non-visual access, that was a blocker. (And it would be harder to do generically across pages, given some blocks might not have focusable elements within your view, or at all).

The same applies to single-page apps where you manage the focus, so links move the focus to the new content. Same for modals, to be consisent.

I've been leaning on the "keyboard operable" aspect, so not requiring a focus indicator where the thing focused is not operable.

[mfairchild365]

In these cases, or in the case of a modal dialog (or a non-modal dialog for that matter) there is a visual indication that something is going on (page position shifts, page goes blank and reloads, dialog appears) so there is a visual indication to users that something is going on. What I'd like to avoid is the user not having any of these clues to set expectations of where the focus is and having the focus disappear.

I agree that in these cases there are other visual hints that focus might have changed, but in the described scenarios it may not be explicitly clear where the focus is or what will get focus next in the tab cycle. The user can probably make an educated guess that focus was moved to somewhere in a general area, but they might not be reassured that focus was actually moved to where they think it was.

I've often created (or recommended) skip to content links which go to the

(or other large block), and providing a focus indicator on that does not seem helpful, and generally gets push-back from designers/product owners (especially as clicking anywhere in the block triggers the indicator). My site is an example.

I agree, and this is a pretty common practice. I think it is also worth noting that there are techniques that allow authors to only show the visual focus indicator if a keyboard event triggered the interaction, and thus hide the styles from mouse users.

I've been leaning on the "keyboard operable" aspect, so not requiring a focus indicator where the thing focused is not operable.

I think this is where I'd like to see clarity. The SC says "keyboard operable user interface" which is not the same as a specific element within the interface that is keyboard operable. It could be argued that if the SC was restricted to only keyboard operable elements, then it would be written as something like "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible for keyboard operable components."

I haven't done any research as to how helpful or harmful showing a visual focus indicator on static content can be, so I don't have much to contribute there. However, I've seen confusion around whether or not this SC applies to static elements, so my hope is that this aspect can be clarified in the understanding document.

[patrickhlauke]

I've seen confusion around whether or not this SC applies to static elements, so my hope is that this aspect can be clarified in the understanding document.

it seems that there's disagreement even within the WG, so...it'll be interesting to see how this shakes out.

my main concern is that if we do say it has to always be visible for scenarios where it's moved programmatically, then that creates an odd loophole where browser-own situations like in-page links don't show focus by default, which either then need to be somehow justified ("unless controlled by the browser..."), OR all default browser behaviors need to be patched or they'll be non-compliant with WCAG (which is a big ask / points to likely failing of UAAG instead).

as said, i'd be in favour of a more nuanced approach where normatively focus on static content is not required, but strongly suggested as a best practice when it's not " explicitly clear where the focus is or what will get focus next in the tab cycle".

[alastc]

The SC says "keyboard operable user interface" which is not the same as a specific element within the interface that is keyboard operable.

I've thought of the 'keyboard operable user interface' as the keyboard-operable aspects of the interface you are using. It is a nuance though.

there are techniques that allow authors to only show the visual focus indicator if a keyboard event triggered the interaction, and thus hide the styles from mouse users.

I've not found them particularly reliable, but happy to be corrected on that.

disagreement even within the WG

I suspect it is mostly a case of outlining the various scenarios, I'm not sure everyone was aware there are harmful aspects to requiring focus indicators for non-interactive elements.

[JAWS-test]

I would like to stress again that both the SC and F78 require focus visibility at all navigation steps, whether the item is operable or not.
No focus visibility is required when the focus is set automatically.

Therefore the Understanding should be corrected.

I would also like to point out that ARIA APG recommends to make certain disabled elements focusable. In this case, the focus should also be visible.

[JAWS-test]

The CSS class :target allows focus display after operation (e.g. for in-page links) without showing a focus when the area is focused directly with the mouse

[patrickhlauke]

I would like to stress again that both the SC and F78 require focus visibility at all navigation steps, whether the item is operable or not.

that is your reading of those. as discussed here, there seem to be differences of opinion.

regarding the SC's normative applicability, it seems to hinge on the "keyboard operable user interface" and exactly what this means (the normative text, as well as the understanding doc, are vague on this point).

F78 only says that the user agent's default focus indication mustn't be suppressed or otherwise obscured ("without providing an author-supplied visual focus indicator"). nothing more. and the procedure to test talks of focusable elements and moving focus to them with the keyboard, which seems to imply that it's about elements in the tab focus order (and not elements that receive programmatic focus).

[patrickhlauke]

as for ARIA APG, it's not a normative spec. it's a working group note, so to me falls within the realm of best practice, not mandatory guidance. (and yes i know we've been around this whole normative vs informative discussion many times before...)

[JAWS-test]

If the focus visibility is restricted to operable elements, this would also mean that, for example, the focus on the list entries in a selection list need not be visible. The select element is an interactive element, the option element within the select element is not. It cannot be operated. The select element can only be operated by navigating through the option elements. In my understanding, however, a double focus visibility must be guaranteed for the select element:

• focus on the select element (by navigation with tab key)
• navigation with the arrow keys through list entries (option elements)

This applies analogously to other interactive elements such as

• radio buttons in radio button groups
• tab in tablist (if the tab panel is already displayed when the focus is received)
• readonly gridcell in grid

[patrickhlauke]

this ties in with another recent discussion in AGWG (though I can't seem to locate it, might have been on email or twitter) about the "concept" of focus (as opposed to which element is strictly the document.activeElement). in the case of options in a select, tabs that are currently active, etc, the conceptual focus is on those elements. and they're operable in the sense that once on there, the user can do something (switch tabs, change to another option in the select, etc). so again, those things are operable in the sense that they allow the user to do something (as opposed to static text where focus was moved to programmatically in order to, for the most part, have it read out by AT/provide a new starting point for focus).

[alastc]

I think this was the start of that discussion about child elements.

Let's quantify the scenarios:

1. Keyboard interactive elements like links & buttons: In the tabindex by default.
2. Static elements (like headings) that have had tabindex="0" added.
3. Static elements with tabindex"-1", that can be focused via script or another link on the page (e.g. skip link targets or new content in an SPA).
4. Child items within a component, such as options in a select, or buttons in a tab-bar.

I think we are all agreeing that 1 & 2 are covered, if you can tab to it, then it must have an indicator.

The upshot of the conversation about sub/child-items (4) was (from memory) that they should and would be covered as the definition of 'focus' (new in the new SC) is about what the user perceives as the focus, not the element per-se.

So in scenario 3, there are good reasons to focus on a container element that is not operable. It is also not tab-able, it is a target rather than keyboard usable in itself.

In the new SC it is more specific to 'user interface component', so there is no argument that a non-interactive thing would be covered.

In the current 2.4.7, I do agree with adding something to the understanding (subject to group approval of course). Perhaps something like:

If the keyboard focus is moved to a non-interactive element, such as a container that is the target of a skip link, that is not considered part of the 'keyboard operable interface' that would show a focus indicator.

[JAWS-test]

In the current 2.4.7, I do agree with adding something to the understanding (subject to group approval of course). Perhaps something like ...

I think the addition is fine. But I think the following would be better:

• It should be added in the sentence that this only refers to cases where the focus is set by JS (e.g. after operating an element) and not when navigating with the keyboard.
• Instead of saying when no focus needs to be visible, say when it needs to be visible
• The wrong sentence ("If there is only one keyboard actionable control on the screen, the success criterion would be met because the visual design presents only one keyboard actionable item") should be removed

[patrickhlauke]

It should be added in the sentence that this only refers to cases where the focus is set by JS (e.g. after operating an element) and not when navigating with the keyboard.

so are we now making it mandatory for things like in-page links (even the standard ones just pointing to named anchors/fragment identifiers) to have a visual indication (using :target in CSS or other method)? if so, that's a substantive change, I'd say...at least it's not something that many of us have historically dinged a site for.

The wrong sentence ("If there is only one keyboard actionable control on the screen, the success criterion would be met because the visual design presents only one keyboard actionable item") should be removed

i do agree that this is not a good example, and a case where even i would actually fail a page for not making it obvious that the one single actionable item is currently focused or not (unless it's also pre-focused or works even when the actual focus itself isn't on it)

[mraccess77]

a double focus visibility must be guaranteed for the select element:

I've can't recall of a double focus indicator being required -- I don't think Firefox has one for select boxes that show more than 1 item at a time. What is important is that the selection and focus states are disambiguated so it's clear what option element is focused and what is selected. If the option element shows focus correctly and that focus goes away when the listbox is not focused then it would seem to pass.

[JAWS-test]

so are we now making it mandatory for things like in-page links

Sorry, I misspoke. What I meant to say was that in sequential navigation (which is usually done with the Tab key and sometimes with the arrow keys), a focus should always be visible, regardless of whether the focused element is operable or not. As far as I understood the discussion, everyone agrees on this point.

Furthermore, everyone seemed to agree that no focus needs to be visible for in-page links, when opening pop-ups etc. (even if it makes sense).

What I consider worthy of discussion is the question of whether a focus must be visible, for a sequential navigation with which I navigate to certain areas without scrolling them into the visible area, because these are permanently visible. An example would be the F6 navigation in Microsoft Excel. This area navigation is also often used by Web applications (such as SAP). Here I also think it is important that the focus is visible. However, I do not know whether this can be required with SC 2.4.7 or can be required with a new SC or whether this is considered unimportant.

[JAWS-test]

I've can't recall of a double focus indicator being required

In my opinion, there is a twofold requirement for focus visibility in selection lists:

• Focus on the selection list
• Focus on the list entry

The browsers solve this differently:

• Firefox always displays a focus frame around the focused list entry, no matter if it is selected or not, and thus fulfills both requirements
• Like Firefox, IE 11 displays a focus frame around the list entry. Additionally the color of the list frame changes
• Chrome shows no focus frame around the focused list entry, but a frame around the entire list. However, in a mutiple select list I cannot see which list entry currently has the focus (would be a violation of SC 2.4.7 - or of UAAG 1.3.1 and UAAG 2.1.2)

[jrpool]

Some comments above seem to say that what is required should depend on whether the latest change in focus has been directly caused by a keyboard action or has been produced by execution of a method in a script that was in turn caused by a keyboard action. If that was the intended recommendation, it seems dubious to me, because users can't be expected to know whether the action they took moved the focus directly or indirectly.

[patrickhlauke]

it's more about (to me): did focus land on an actual focusable/interactive element, or was it just moved to some static content. if it lands (as a result of following a relative in-page link for instance) on a heading, browsers by default would not show any focus indication by default. and i'd argue it would be confusing for keyboard users if they did see an actual focus outline there on the heading, when it's not actually interactive. and yes, i'd find the differentiation of "as a result of scripting or just native browser behavior" rather pointless, as at the end of the day users don't care HOW something happened (and they're not in a position to know most of the time, or to care). feels that that differentiation is more something aimed at making the idea more palatable to authors...

[jrpool]

Whether it's more confusing to see focus indicated on a non-actionable element, or not to see focus indicated at all, presumably varies among users. It would be great if there were good empirical data on that. Meanwhile, a possibility that seems not to have been mentioned above is to employ two different focus indicators: one for actionable elements and the other for static ones. Thereby one might be able to ensure that (most) users know what has the focus at all times, and thus guess right about where a TAB or SHIFT-TAB will next move the focus (helping to realize technique G59), but not be misled into expecting something to happen if they press ENTER or alphanumerics while a static element has the focus. Designers would also presumably be able to craft a focus indicator for a static element that did not offend them aesthetically.

[patrickhlauke]

the problem here is that regardless of how good the idea of a dual/variable focus indicator is, no browser implements anything along those lines natively. and requiring this sort of approach under 2.4.7 would, in my view, retrospectively change the requirement of this SC (and it would immediately make millions of sites that just use, say, relative in-page links invalid, retrospectively).

[jrpool]

Of course. I intended only to suggest a possible approach to implementing an existing technique, not to advocate a new success criterion. My implication is this: If it turns out that WCAG conformity requires that the focus always be visible in a UI that can be keyboard-operated, regardless of whether the focus is on a static or actionable element, this does NOT require the focus indication to be identical between elements of those types.