-
Notifications
You must be signed in to change notification settings - Fork 328
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.
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
base: main
Are you sure you want to change the base?
Conversation
|
Reformatted the additions into the note to account for the changed structure since this PR was first filed, to clear the merge conflict |
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| <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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
patrickhlauke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add extra notes about single focusable elements, and initial state of focus on page opening etc.
Fixes #1001