Skip to content

"Focusable element has no keyboard trap via standard navigation" [a1b64e]: fix Failed example and add clarification #1905

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

Merged
merged 17 commits into from
Jan 17, 2023
Merged

"Focusable element has no keyboard trap via standard navigation" [a1b64e]: fix Failed example and add clarification #1905

Changes from all commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
949cf31
Update failed example and add background note
Jym77 Aug 4, 2022
0f1be60
Clean up
Jym77 Aug 4, 2022
8c34b83
Accept suggestion from code review
Jym77 Aug 5, 2022
e02b8f3
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Aug 5, 2022
ee68a93
Fix link name
Jym77 Sep 8, 2022
ecc8a7c
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Sep 8, 2022
53fba6e
Move note to assumption
Jym77 Sep 15, 2022
e735807
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Sep 15, 2022
e9ef6f7
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Oct 27, 2022
04da2fc
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Nov 24, 2022
3dd8177
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Dec 15, 2022
5913004
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Jan 5, 2023
29a1f91
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Jan 9, 2023
37053bf
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Jan 9, 2023
7b5c4b0
Move assumption to background note
Jym77 Jan 12, 2023
e2cd3ac
Merge branch 'develop' into keyboard-trap-clarification
Jym77 Jan 17, 2023
66d73e0
Re-trigger tests
Jym77 Jan 17, 2023
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
8 changes: 6 additions & 2 deletions _rules/focusable-no-keyboard-trap-standard-nav-a1b64e.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ This rule applies to any [HTML or SVG element][] that is [focusable][].

For each target element, focus can cycle to the browser UI by using [standard keyboard navigation](#standard-keyboard-navigation).

**Note:** Cycling back to the browser UI can be done both by moving forward through the tab order and by moving backwards. It is not possible to fulfill this expectation by using browser specific shortcuts to return to the browser UI.
**Note:** It is not possible to fulfill this expectation by using browser specific shortcuts to return to the browser UI.
Copy link
Member

Choose a reason for hiding this comment

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

I'm not so sure that things that can only be exited with shift+tab should pass this SC. I think we need to get clarity on that. This note shouldn't have been a note. Knowing whether its backward, forward, or both needs to be in the expectation, but then by taking this out of the note without changing the expectation we're making the rule less clear.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This note shouldn't have been a note.

Which is why we upgrade it to an Assumption 😁

The "one way is enough" view has been discussed on CG call on July 14th, check also the action point summary.

Thus said, I do agree that our definition of "standard keyboard navigation" lists 6 keys (or combination) and the expectation is not fully clear whether one of these is enough (technically, it is because the def is "one or more of [these 6 keys]", so cycling back to UI using only one of the listed method does fulfil the definition).


## Assumptions

Expand All @@ -42,6 +42,8 @@ There are no accessibility support issues known.

## Background

This rule only requires navigation in one direction (either forward or backward), not both, and not a specific one. It is clear that not being able to escape a focus trap in any direction is a failure of [Success Criterion 2.1.2 No keyboard trap][sc212]. However, it is less clear that being able to escape in only one direction is enough to satisfy it. If [Success Criterion 2.1.2 No keyboard trap][sc212] requires the possibility to escape the trap in a specific way (e.g. forward [standard keyboard navigation](#standard-keyboard-navigation)) or in both directions, this rule may pass while the criterion is not satisfied.

### Bibliography

- [Understanding Success Criterion 2.1.2: No Keyboard Trap](https://www.w3.org/WAI/WCAG21/Understanding/no-keyboard-trap.html)
Expand Down Expand Up @@ -80,13 +82,14 @@ This element is made [focusable][] by the `tabindex` attribute, even if it is no

#### Failed Example 1

This [focusable][] element creates a keyboard trap bringing focus to the `button`.
This [focusable][] element creates a keyboard trap bringing focus to the `button`. Note that if one of the links is removed, the focus may jump to the browser UI before the timeout expires, at which point the `this.focus()` trap cannot trigger anymore.

```html
<a href="#">Link 1</a>
<button onblur="setTimeout(() => this.focus(), 10)">
Button1
</button>
<a href="#">Link 2</a>
```

#### Failed Example 2
Expand Down Expand Up @@ -151,3 +154,4 @@ There is no [focusable][] element.

[focusable]: #focusable 'Definition of focusable'
[html or svg element]: #namespaced-element
[sc212]: https://www.w3.org/TR/WCAG21/#no-keyboard-trap 'Success Criterion 2.1.2 No Keyboard Trap'