Skip to content

Commit

Permalink
Merge pull request #3533 from w3c/issue-3446
Browse files Browse the repository at this point in the history
Focus Not Obscured (aa/aaa): revise uses of 'hidden'
  • Loading branch information
mbgower committed Jan 18, 2024
2 parents 0625fbf + 3389d1d commit 29376da
Show file tree
Hide file tree
Showing 4 changed files with 9 additions and 9 deletions.
2 changes: 1 addition & 1 deletion guidelines/sc/22/focus-not-obscured-enhanced.html
Original file line number Diff line number Diff line change
Expand Up @@ -7,5 +7,5 @@ <h4>Focus Not Obscured (Enhanced)</h4>

<p>When a <a>user interface component</a> receives keyboard focus, no part of the component is hidden by author-created content.</p>


</section>
2 changes: 1 addition & 1 deletion guidelines/sc/22/focus-not-obscured-minimum.html
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,6 @@ <h4>Focus Not Obscured (Minimum)</h4>

<p class="note">Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.</p>

<p class="note">Content opened by the <em>user</em> may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.</p>
<p class="note">Content opened by the <em>user</em> may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.</p>

</section>
6 changes: 3 additions & 3 deletions understanding/22/focus-not-obscured-enhanced.html
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ <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 hide 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 covers 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. This form of obscuring is <em>not</em> in scope for this Success Criterion. While less than 100 percent opacity is not causing the component to be <q>hidden</q>, such semi-opaque overlaps may cause a failure of <a href="../understanding/focus-appearance.html">2.4.11 Focus Appearance</a>. When a focus indicator can be covered by a semi-opaque component, the the focus indicator should be assessed against 2.4.11. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus.</p>
<p>Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. This form of obscuring is <em>not</em> in scope for this Success Criterion. While less than 100 percent opacity is not causing the component to be <q>visually hidden</q>, such semi-opaque overlaps may cause a failure of <a href="../understanding/focus-appearance.html">2.4.11 Focus Appearance</a>. When a focus indicator can be covered by a semi-opaque component, the the focus indicator should be assessed against 2.4.11. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus.</p>
</section>
<section id="benefits">
<h2>Benefits of Focus Not Obscured (Enhanced)</h2>
Expand All @@ -47,7 +47,7 @@ <h2>Benefits of Focus Not Obscured (Enhanced)</h2>
<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 sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not at all obscured 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>
Expand All @@ -70,7 +70,7 @@ <h3>Additional Techniques (Advisory)</h3>
<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 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>
<li>A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page, a focused item is partially obscured 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>
Expand Down
8 changes: 4 additions & 4 deletions understanding/22/focus-not-obscured-minimum.html
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ <h2>Focus Not Obscured (Minimum) Success Criterion text</h2>

<p class="note">Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content is considered for testing and conformance of this Success Criterion.</p>

<p class="note">Content opened by the <em>user</em> may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.</p>
<p class="note">Content opened by the <em>user</em> may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.</p>

</section>

Expand All @@ -37,13 +37,13 @@ <h2>Intent of Focus Not Obscured (Minimum)</h2>

<p>The intent of this Success Criterion is to ensure that the item receiving keyboard focus is always partially 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>In recognition of the complex responsive designs common today, this AA criterion allows for the component receiving focus to be <em>partially</em> obscured by other author-created content. A partly obscured component can still be very visible, although the more of it that is obscured, the less easy it is to see. For that reason, authors should attempt to design interactions to reduce the degree and frequency with which the item receiving focus is partly obscured. For best visibility, <em>none</em> of the component receiving focus should be hidden. This preferred outcome is covered by the AAA criterion <a href="focus-not-obscured-enhanced.html">Focus Not Obscured (Enhanced)</a>.</p>
<p>In recognition of the complex responsive designs common today, this AA criterion allows for the component receiving focus to be <em>partially</em> obscured by other author-created content. A partly obscured component can still be very visible, although the more of it that is obscured, the less easy it is to see. For that reason, authors should attempt to design interactions to reduce the degree and frequency with which the item receiving focus is partly obscured. For best visibility, <em>none</em> of the component receiving focus should be obscured. This preferred outcome is covered by the AAA criterion <a href="focus-not-obscured-enhanced.html">Focus Not Obscured (Enhanced)</a>.</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 entirely 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 causing the component to be <q>entirely hidden</q>, such semi-opaque overlaps may cause a failure of <a href="../understanding/non-text-contrast.html">1.4.11 Non-text Contrast</a>. When a focus indicator can be covered by a semi-opaque component, the ability of the focus indicator to pass 1.4.11 should be evaluated (and pass) while the focus indicator is under the semi-opaque component. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has 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 causing the component to be <q>entirely obscured</q>, such semi-opaque overlaps may cause a failure of <a href="../understanding/non-text-contrast.html">1.4.11 Non-text Contrast</a>. When a focus indicator can be covered by a semi-opaque component, the ability of the focus indicator to pass 1.4.11 should be evaluated (and pass) while the focus indicator is under the semi-opaque component. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus.</p>

<section id="Movable">
<h3>User-movable content</h3>
Expand Down Expand Up @@ -165,7 +165,7 @@ <h2>Benefits of Focus Not Obscured (Minimum)</h2>
<h2>Examples of Focus Not Obscured (Minimum)</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 completely 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 sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not completely visually obscured 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 full-width 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 major portion of the cookie approval dialog remains on screen (until selections are made and submitted), and so the major portion of the keyboard focus indicator remains visible.</li>
<li>A notification is implemented as a sticky header and the keyboard focus is moved to the notification so at least part of the focus indicator is in view. The notification disappears when it loses focus so it does not obscure any other controls, and part of the prior keyboard focus indicator is visible.</li>
</ul>
Expand Down

0 comments on commit 29376da

Please sign in to comment.