Skip to content

Update Understanding "focus visible" (SC 2.4.7) #1022

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Update Understanding "focus visible" (SC 2.4.7) #1022

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bb7fc83
Update focus-visible.html
Jan 27, 2020
fe26880
Merge branch 'main' into SC2.4.7
patrickhlauke Jun 27, 2025
3b995c6
Merge branch 'main' into SC2.4.7
patrickhlauke Jul 4, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion understanding/20/focus-visible.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,11 +25,13 @@ <h2>Intent of Focus Visible</h2>
<p>The purpose of this success criterion is to help a person know which element has the
keyboard focus.
</p>

<p>“Mode of operation” accounts for user agents which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used. Authors are responsible for providing at least one mode of operation where the focus is visible. In most cases there is only one mode of operation so this success criterion applies. The focus indicator must not be time limited, when the keyboard focus is shown it must remain.</p>

<div class="note">
<p>There may be situations where mouse/pointer users could also benefit from having a visible focus indicator, even though they did not set focus to an element using the keyboard. As a best practice, consider still providing an explicit focus indicator for these cases.</p>

<p>If there is only one keyboard focusable control on the screen, the success criterion would be met because the visual design presents only one keyboard focusable item. The success criterion does not require the focus to be visible intially, e.g. after opening a new page, when displaying a pop-up or after activating in-page links. However, it is recommended to show the focus in these cases as well.</p>
Copy link
Contributor

@gundulaniemann gundulaniemann Jul 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is the user supposed to work when the focus is not shown initially? How does a screen reader user perceive what happened to the focus?
If the focus is not visible initially, the user doesn't see where the focus is and might initiate an action that is not wanted. Also, having to interact to see the focus reduces efficiency considerable and distracts from the task all the time.

Copy link
Contributor

@mbgower mbgower Jul 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I agree with this addition (and btw, there's a typo in "initially"):

The success criterion does not require the focus to be visible intially

There is a difference between a page that does not have an element in focus initially, and one where there is a focusable element that is not properly shown as active. I don't think this nuance is clear, nor how to address in respect to Focus Visible. I'm also not sure that the number of focusable controls on the screen is relevant to that.

I do not think this PR sufficiently captures or addresses the initial question in #1001.

I think these are good questions to provide guidance on:

  • can an inoperable element on a page take focus?
  • if so, should it have a focus indicator?
  • if so, must it have a focus indicator to meet Focus Visible (and not doing so is a failure of 2.4.7)?
  • conversely, is there a time when inoperable elements receiving focus constitutes a failure of WCAG?

I think more detail is required, and I don't think this PR is sufficient as written. I'm okay to keep the scope of this change contained, but I think it should clearly answer at least one of the questions that seems to exist in #1001 discussion.

</div>

<p>Note that a keyboard focus indicator can take different forms. <span class="wcag22">While Focus Visible does not specify what that form is, <a href="focus-appearance">2.4.13 Focus Appearance (Level AAA)</a> provides guidance on creating a consistent, visible indicator.</span></p>
Expand Down