From a559ab7b3cbd653a5dff3046f5173033f47e2ed3 Mon Sep 17 00:00:00 2001 From: Giacomo Petri Date: Wed, 20 Mar 2024 11:18:52 +0100 Subject: [PATCH 1/2] Fix wrong SC reference + typo --- understanding/22/focus-not-obscured-enhanced.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/understanding/22/focus-not-obscured-enhanced.html b/understanding/22/focus-not-obscured-enhanced.html index e85471b042..36e65eb039 100644 --- a/understanding/22/focus-not-obscured-enhanced.html +++ b/understanding/22/focus-not-obscured-enhanced.html @@ -22,7 +22,7 @@

Intent of Focus Not Obscured (Enhanced)

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.

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.

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 scroll padding 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.

-

Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. This form of obscuring is not in scope for this Success Criterion. While less than 100 percent opacity is not causing the component to be visually hidden, such semi-opaque overlaps may cause a failure of 2.4.11 Focus Appearance. 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.

+

Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. This form of obscuring is not in scope for this Success Criterion. While less than 100 percent opacity is not causing the component to be visually hidden, such semi-opaque overlaps may cause a failure of 1.4.11 Focus Appearance and/or 2.4.13 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the focus indicator should be assessed against 1.4.11 and 2.4.13. 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.

Benefits of Focus Not Obscured (Enhanced)

From b39db4d1ea9e30309d9a02db6f6b57b70008d9cb Mon Sep 17 00:00:00 2001 From: Giacomo Petri Date: Wed, 20 Mar 2024 12:00:04 +0100 Subject: [PATCH 2/2] Update understanding/22/focus-not-obscured-enhanced.html Co-authored-by: Patrick H. Lauke --- understanding/22/focus-not-obscured-enhanced.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/understanding/22/focus-not-obscured-enhanced.html b/understanding/22/focus-not-obscured-enhanced.html index 36e65eb039..7fc428b746 100644 --- a/understanding/22/focus-not-obscured-enhanced.html +++ b/understanding/22/focus-not-obscured-enhanced.html @@ -22,7 +22,7 @@

Intent of Focus Not Obscured (Enhanced)

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.

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.

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 scroll padding 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.

-

Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. This form of obscuring is not in scope for this Success Criterion. While less than 100 percent opacity is not causing the component to be visually hidden, such semi-opaque overlaps may cause a failure of 1.4.11 Focus Appearance and/or 2.4.13 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the focus indicator should be assessed against 1.4.11 and 2.4.13. 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.

+

Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. This form of obscuring is not in scope for this Success Criterion. While less than 100 percent opacity is not causing the component to be visually hidden, such semi-opaque overlaps may cause a failure of 1.4.11 Non-text Contrast and/or 2.4.13 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the focus indicator should be assessed against 1.4.11 and 2.4.13. 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.

Benefits of Focus Not Obscured (Enhanced)