Skip to content

Improve the SC 2.1.2 No Keyboard Trap Understanding #4316

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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
+145 −125
Draft

Improve the SC 2.1.2 No Keyboard Trap Understanding #4316

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8f76950
First attempt to improve the SC 2.1.2 No Keyboard Trap Understanding
yatil Apr 4, 2025
34f0d7d
- Language improvements (I hope)
yatil Apr 5, 2025
d6d1341
Update understanding/20/no-keyboard-trap.html
yatil Jul 3, 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
270 changes: 145 additions & 125 deletions understanding/20/no-keyboard-trap.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,127 +1,147 @@
<!DOCTYPE html>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="UTF-8"></meta>
<title>Understanding No Keyboard Trap</title>
<link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove"/>
</head>
<body>
<h1>Understanding No Keyboard Trap</h1>

<section id="brief">
<h2>In brief</h2>
<dl>
<dt>Goal</dt><dd>Keyboard users don't get stuck.</dd>
<dt>What to do</dt><dd>Ensure users always know how to navigate away from components.</dd>
<dt>Why it's important</dt><dd>People who rely on the keyboard often have no other means to navigate.</dd>
</dl>

</section>

<section id="intent">
<h2>Intent of No Keyboard Trap</h2>


<p>The intent of this success criterion is to ensure that that content does not "trap"
keyboard focus within subsections of content on a web page. This is a common problem
when multiple formats are combined within a page and rendered using plug-ins or embedded
applications.
</p>

<p>There may be times when the functionality of the web page restricts the focus to a
subsection of the content, as long as the user knows how to leave that state and "untrap"
the focus.
</p>


</section>
<section id="benefits">
<h2>Benefits of No Keyboard Trap</h2>


<ul>

<li>People who rely on a keyboard or keyboard interface to use the Web including people
who are blind and people with physical disabilities.
</li>

</ul>

</section>

<section id="examples">
<h2>Examples of No Keyboard Trap</h2>

<dl>
<dt>A calendar widget</dt>
<dd>A calendar widget allows users to add, remove or update items in their calendar using
the keyboard. The controls in the widget are part of the tab order within the Web
page, allowing users to tab through the controls in the widget as well as to any links
or controls that follow.</dd>
<dt>A puzzle applet</dt>
<dd>Once a user tabs into an applet, further tabs and other keystrokes are handled by
the applet. Instructions describing the keystroke used to exit the applet are provided
prior to the applet as well as within the applet itself.</dd>
<dt>A modal dialog box</dt>
<dd>A web application brings up a dialog box. At the bottom of the dialog are two buttons,
Cancel and OK. When the dialog has been opened, focus is trapped within the dialog;
tabbing from the last control in the dialog takes focus to the first control in the
dialog. The dialog is dismissed by activating the Cancel button or the OK button.</dd>
</dl>

</section>

<section id="resources">
<h2>Resources for No Keyboard Trap</h2>


</section>

<section id="techniques">
<h2>Techniques for No Keyboard Trap</h2>


<section id="sufficient">
<h3>Sufficient Techniques for No Keyboard Trap</h3>


<ul>

<li>

<a href="../Techniques/general/G21" class="general">Ensuring that users are not trapped in content</a>

</li>

</ul>

</section>

<section id="advisory">
<h3>Additional Techniques (Advisory) for No Keyboard Trap</h3>


</section>

<section id="failure">
<h3>Failures for No Keyboard Trap</h3>


<ul>

<li>

<a href="../Techniques/failures/F10" class="failure">Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining
multiple content formats in a way that traps users inside one format type
</a>

</li>

</ul>

</section>

</section>

</body>
</html>

<head>
<meta charset="UTF-8">
</meta>
<title>Understanding No Keyboard Trap</title>
<link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove" />
</head>

<body>
<h1>Understanding No Keyboard Trap</h1>

<section id="brief">
<h2>In brief</h2>
<dl>
<dt>Goal</dt>
<dd>Keyboard users don't get stuck.</dd>
<dt>What to do</dt>
<dd>Ensure users always know how to navigate away from components.</dd>
<dt>Why it's important</dt>
<dd>People who rely on the keyboard often have no other means to navigate.</dd>
</dl>

</section>

<section id="intent">
<h2>Intent of No Keyboard Trap</h2>


<p>The intent of this success criterion is to ensure that that content does not “trap” the
keyboard focus within subsections of content on a web page or app. It is common to restrict
Copy link
Member

Choose a reason for hiding this comment

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

the "It is common..." insert here seems out of place. I'd move it to the next paragraph, and change this back to talking about the problem

the focus to a specific dialog or popover. It can also occur if content is rendered using
plug-ins or when content is embedded.
</p>

<p>As long as the user knows how to leave a subsection of content (and “untrap” the focus),
a web page can restrict the focus to a subsection of the content. In some cases, temporarily
restricting the focus to a specific component is useful to help users understand where they
are on the page and what interactions are possible. It also prevents the focus from being
obscured, for example behind a dialog.
</p>

<p>The keyboard focus is not considered as trapped when the user can navigate away from a UI
component using the unmodified tab or arrow keys or when another “standard exit method” exists.
What is a “standard exit method” depends on the user’s hardware and software. A press
of the <kbd>ESC</kbd> key is such a “standard exit method”. When the press of the hardware back
Copy link
Member

Choose a reason for hiding this comment

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

the "When" sentence doesn't quite work structure-wise

button on certain mobile operating systems “untraps” the keyboard focus is also sufficient.
In addition, some screen readers have other ways, like swipe gestures, that result in a
pressed <kbd>ESC</kbd> key.
</p>


</section>
<section id="benefits">
<h2>Benefits of No Keyboard Trap</h2>


<ul>

<li>People who rely on a keyboard or keyboard interface to use the Web including people
who are blind and people with physical disabilities.
</li>

</ul>

</section>

<section id="examples">
<h2>Examples of No Keyboard Trap</h2>

<dl>
<dt>A modal dialog box</dt>
<dd>A web application brings up a dialog box. At the bottom of the dialog are two buttons,
Cancel and OK. When the dialog has been opened, focus is trapped within the dialog;
tabbing from the last control in the dialog takes focus to the first control in the
dialog. The dialog is dismissed by activating the Cancel button, the OK button, or the
<kbd>ESC</kbd> key.
<dt>A calendar widget</dt>
<dd>A calendar widget allows users to add, remove or update items in their calendar using
the keyboard. The controls in the widget are part of the tab order within the Web
page, allowing users to tab through the controls in the widget as well as to any links
or controls that follow.</dd>
<dt>A puzzle applet</dt>
<dd>Once a user tabs into an applet, further tabs and other keystrokes are handled by
the applet. Instructions describing the keystroke used to exit the applet are provided
prior to the applet as well as within the applet itself.</dd>
</dd>
</dl>

</section>

<section id="resources">
<h2>Resources for No Keyboard Trap</h2>


</section>

<section id="techniques">
<h2>Techniques for No Keyboard Trap</h2>


<section id="sufficient">
<h3>Sufficient Techniques for No Keyboard Trap</h3>


<ul>

<li>

<a href="../Techniques/general/G21" class="general">Ensuring that users are not trapped in content</a>

</li>

</ul>

</section>

<section id="advisory">
<h3>Additional Techniques (Advisory) for No Keyboard Trap</h3>


</section>

<section id="failure">
<h3>Failures for No Keyboard Trap</h3>


<ul>

<li>

<a href="../Techniques/failures/F10" class="failure">Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining
multiple content formats in a way that traps users inside one format type
</a>

</li>

</ul>

</section>

</section>

</body>

</html>