Skip to content
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

Update Understanding Focus Not Obscured #3163

Merged
merged 17 commits into from May 18, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
156 changes: 63 additions & 93 deletions understanding/22/focus-not-obscured-enhanced.html
@@ -1,98 +1,68 @@
<!DOCTYPE html>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="UTF-8"></meta>
<title>Understanding Focus Not Obscured (Enhanced)</title>
<link rel="stylesheet" type="text/css" href="../../css/editors.css" class="remove"></link>
<meta charset="UTF-8" />
<title>Understanding Focus Not Obscured (Enhanced)</title>
<link rel="stylesheet" type="text/css" href="../../css/editors.css" class="remove" />
</head>
<body>
<h1>Understanding Focus Not Obscured (Enhanced)</h1>

<section id="status" class="advisement">
<h2>Status</h2>
<p>This understanding document is part of the <a href="https://w3c.github.io/wcag/guidelines/22/"><strong>draft</strong> WCAG 2.2 content</a>. It may change or be removed before the final WCAG 2.2 is published.</p>
</section>


<section class="remove">

<h2>Focus Not Obscured Success Criterion text</h2>
<blockquote>
<p>When a <a>user interface component</a> receives keyboard focus, no part of the component is hidden by author-created content.</p>
</blockquote>
</section>

<section id="brief">
<h2>In brief</h2>
<dl>
<dt>Objective</dt><dd>Do not cover any part of the item with focus</dd>
<dt>Author task</dt><dd>Ensure no content obstructs the item receiving keyboard focus</dd>
<dt>Key beneficiaries</dt><dd>Some users with cognitive disabilities and sighted users reliant on keyboard interaction</dd>
</dl>

</section>

<section id="intent">

<h2>Intent of Focus Not Obscured (Enhanced)</h2>

<p>The purpose of this Success Criterion is to ensure that a component with keyboard focus is visible. This criterion is closely related to <a href="./focus-not-obscured.html">Focus Not Obscured (Minimum)</a> but requires that the whole of the component is visible.</p>

</section>

<section id="benefits">
<h2>Benefits of Focus Not Obscured (Enhanced)</h2>

<ul>
<li>This Success Criterion helps anyone who relies on the keyboard to operate the page by letting them visually determine the component on which keyboard operations will interact at any point in time.</li>
<li>People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.</li>
</ul>

</section>

<section id="examples">
<h2>Examples of Focus Not Obscured (Enhanced)</h2>

<ul>
<li>A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not overlapped by the footer at all.</li>
</ul>

</section>

<section id="resources">
<h2>Resources</h2>

</section>


<section id="techniques">
<h2>Techniques for Focus Not Obscured (Enhanced)</h2>


<section id="sufficient">
<h3>Sufficient Techniques</h3>

<ol>
<li>
<a href="../../techniques/css/C43">C43</a>
</li>
<li>
CSS: Using scroll-padding to ensure a sticky header does not entirely obscure the focused item (Potential future technique).
</li>
</ol>

</section>

<section id="advisory">
<h3>Additional Techniques (Advisory)</h3>

</section>

<section id="failure">
<h3>Failures</h3>
</section>

</section>

<h1>Understanding Focus Not Obscured (Enhanced)</h1>
<section id="status" class="advisement">
<h2>Status</h2>
<p>This understanding document is part of the <a href="https://w3c.github.io/wcag/guidelines/22/"><strong>draft</strong> WCAG 2.2 content</a>. It may change or be removed before the final WCAG 2.2 is published.</p>
</section>
<section class="remove">
<h2>Focus Not Obscured (Enhanced) Success Criterion text</h2>
<blockquote>
<p>When a <a>user interface component</a> receives keyboard focus, no part of the component is hidden by author-created content.</p>
</blockquote>
<p class="note">If the interface is configurable so that the user can reposition content such as toolbars and non-modal dialogs, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.</p>
</section>
<section id="intent">
<h2>Intent of Focus Not Obscured (Enhanced)</h2>
<p>The intent of this Success Criterion is to ensure that the item receiving keyboard focus is always visible in the user's viewport. For sighted people who rely on a keyboard (or on a device that operates through the keyboard interface, such as a switch or voice input), knowing the current point of focus is critical. The component with focus signals the interaction point on the page. Where users cannot see the item with focus, they may not know how to proceed, or may even think the system has become unresponsive.</p>
<p>Typical types of content that can overlap focused items are sticky footers, sticky headers, and non-modal dialogs. As a user tabs through the page, these layers of content can obscure the item receiving focus, along with its focus indicator.</p>
<p>A notification implemented as sticky content, such as a cookie banner, will fail this Success Criterion if it partially obscures a component receiving focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding">scroll padding</a> so the banner does not overlap other content. Notifications that do not require user action could also meet this criterion by closing on loss of focus.</p>
<p>Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. While less than 100 percent opacity is not <q>entirely hidden</q>, it is causing the component to be <q>partially hidden</q> and a failure of this Success Criterion. Such semi-opaque overlaps may <em>also</em> cause a failure of <a href="../understanding/focus-appearance.html">2.4.11 Focus Appearance</a>.</p>
</section>
<section id="benefits">
<h2>Benefits of Focus Not Obscured (Enhanced)</h2>
<ul>
<li>Sighted users who rely on a keyboard interface to operate the page will be able to see the component which gets keyboard focus. Such users include those who rely on devices which use the keyboard interface, including speech input, sip-and-puff software, on-screen keyboards, scanning software, and a variety of assistive technologies and alternate keyboards.</li>
<li>People with limited or low vision, who may primarily use a pointer for screen orientation and repositioning, nonetheless benefit from a fuller visible indication of the current point of keyboard interaction, especially where magnification reduces the overall viewing portion of the screen.</li>
<li>People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to more easily discover where the focus is located.</li>
</ul>
</section>
<section id="examples">
<h2>Examples of Focus Not Obscured (Enhanced)</h2>
<ul>
<li>A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not at all hidden by the footer because content in the viewport scrolls up to always display the item with keyboard focus using <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding" rel="nofollow">scroll padding</a>.</li>
<li>A page has a large (30% wide) cookie approval dialog. The dialog is modal, preventing access to the other controls in the page until it has been dismissed. Focus is not obscured because the cookie approval dialog (including the focus indicator) remains on screen until selections are made and submitted.</li>
<li>A notification is implemented as a sticky header and the keyboard focus is moved to the notification. The notification disappears when it loses focus, and does not obscure any other controls (including the focus indicator visible prior to the notification).</li>
</ul>
</section>
<section id="resources">
<h2>Resources</h2>
</section>
<section id="techniques">
<h2>Techniques for Focus Not Obscured (Enhanced)</h2>
<section id="sufficient">
<h3>Sufficient Techniques</h3>
<ol>
<li> <a href="../../techniques/css/C43">C43</a> Using CSS margin and scroll-margin to un-obscure content </li>
</ol>
</section>
<section id="advisory">
<h3>Additional Techniques (Advisory)</h3>
</section>
<section id="failure">
<h3>Failures</h3>
<ul>
<li>An interaction that causes content to appear over the component with keyboard focus, visually covering part of the focus indicator. This behavior might be encountered with advertising or promotional material meant to provide more information about a product as the user navigates through a catalogue.</li>
<li>A light box or other semi-opaque effect that overlaps the focus indicator. The obscuring may triggered by a component receiving focus or from other interation, but is a failure regardless.</li>
bruce-usab marked this conversation as resolved.
Show resolved Hide resolved
<li>A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page, a focused item is partially hidden by the footer because content in the viewport scrolls without sufficient <a href="https://www.w3.org/TR/css-scroll-snap/#propdef-scroll-padding" rel="nofollow">scroll padding</a>.</li>
</ul>
</section>
</section>
</body>
</html>
</html>