Add F114: Failure technique for focus obscured by overlay #4673
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
while i realize the primary goal of this new technique is to show how this fails 2.4.11, should it not also mention this example fails other SCs as well? Other failing techniques similarly list the other SC(s) that are applicable |
|
Hmmm... I think for a failure of 2.4.11, it does not matter whether the obscuring object is opaque or semitransparent. With modal dialogs, focus should not reach the page background, so that is the primary failure (of 2.4.3) in the scenario outlined. It the failure occurs and the focus is not (or not well enough) visible on darkened background as a consequence, this seems at least secondary. So it is difficult to pin down this way because more than one SC fail (1.4.11 also being a candidate). The failure condition also would need to take into account if the dialog was explictily opened by the user (think of a chat window) or can be moved around / repositioned. If so, lack of contrast would more likely be a 1.4.11 failure (not-text contrast). |
|
@kfranqueiro Any advise on this? |
| </section><section id="tests"><h2>Tests</h2> | ||
| <section class="procedure"><h3>Procedure</h3> | ||
| <ol> | ||
| <li>Navigate through the page using keyboard navigation (Tab key) to move focus to various interactive elements.</li> |
There was a problem hiding this comment.
| <li>Navigate through the page using keyboard navigation (Tab key) to move focus to various interactive elements.</li> | |
| <li>Navigate through the page using keyboard navigation to move focus to each interactive element.</li> |
| <ol> | ||
| <li>Navigate through the page using keyboard navigation (Tab key) to move focus to various interactive elements.</li> | ||
| <li>Check if any semi-opaque overlays or translucent content appear that could cover focus indicators.</li> | ||
| <li>For each focusable element that could be covered by such an overlay, measure the contrast ratio of the focus indicator while the overlay is present.</li> |
There was a problem hiding this comment.
| <li>For each focusable element that could be covered by such an overlay, measure the contrast ratio of the focus indicator while the overlay is present.</li> | |
| <li>For each element receiving focus while obscured by the overlay, measure the contrast ratio of the item with focus or its focus indicator.</li> |
|
There's another, new, design technique that this would cover: on some sites, when a user scrolls down the page, what looks like an automatically opened modal dialog appears, usually with a "subscribe to my blog" message. All of the page's content around the "dialog" is dimmed with a fake backdrop, making the "dialog" stand out. The "dialog" is just a section of content on the page and as the user continues to scroll, the backdrop disappears. |
|
On Backlog call, we noted that this is part of Understanding:
|
|
Here's an example of my comment above—this is still not common, but I've seen it on several sites in the past month. When the "subscribe" section comes into view, it's visually presented as a modal dialog, but all that happens is the rest of the page is dimmed out, resulting in links underneath the "backdrop" being visually obscured. |
|
I really liked the example shared. I was not the call today. Is the suggestion to replace the failure technique to scrolling modal pop up ? I can update that. |
|
On Friday's WCAG 2 TF call, we got into a debate about ways to fail semi-transparent overlays that are non-modal. I believe @scottaohara, @kfranqueiro and some others were saying 4.1.2 Name, Role, Value can be used to fail these. I was unsuccessful in describing a few scenarios where I thought this wouldn't work, so I thought I'd supply a bit more info. First off, lightbox effects -- that is, a rendering of the background of a dialog that degrades its visual appearance, and implies it is inert -- tend to be applied to modal dialogs. But isn't it possible to use a lightbox effect on an html5 However, that was not the primary scenario I was trying to address. I was trying to address scenarios where overlays are not fully opaque. I'm not talking about a lightbox effect. I'm talking about the opacity of the 'box' drawn onto the screen in which the overlay appears. This article on glassmorphism by NN/g covers some of what I'm talking about. Here's an example of one in the wild. Ignore the size and specific use case. In this screen snippet it appears to obscure almost all the screen, but say this one is covering 1/8 of the viewable area, and is meant as one of those irritating 'try me' patterns. Say it floats over top of other content, so that it ends up covering controls. Say it appears when the page loads and does not take focus right away. In other words, it is exactly the phenomenon intended to be failed by Focus Not Obscured (Minimum). The problem is that since it is not fully opaque, it does not meet the language of "entirely hidden". I don't see how we can use 4.1.2 to fail this. So this is the kind of situation I'm saying can reference 1.4.11 Non-text Contrast as a means to fail. Hope that helps give some context. I can think of no other criteria that can be brought to bear. Can anyone? @detlevhfischer suggested 2.4.3 Focus Order, but that seems shaky, especially in a situation where the overlay is floating. Some would argue that logically it should be in the tab order following the main content, and regardless of where it appears in the order, it is on a different layer than the rest of the content, and therefore trying to say its position in the focus order constitutes a fail seems tenuous. |
Add F114: Failure Technique for Focus Indicators Obscured by Semi-Opaque Overlays
Resolving for #3203
Problem
WCAG 2.2 Understanding document for SC 2.4.11 Focus Not Obscured (Minimum) mentions that semi-opaque overlays can reduce focus indicator visibility, but only describes the problem informally. There was no dedicated Failure Technique (F114) that auditors could reference when testing SC 1.4.11 Non-text Contrast failures where focus indicators are dimmed by overlays.
Solution
Created F114 failure technique with comprehensive testing guidance and a working example that demonstrates the issue.
Changes Made
New Files:
techniques/failures/F114.html- Complete failure technique documentationworking-examples/css-focus-obscured-overlay/index.html- Interactive working exampleModified Files:
understanding/understanding.11tydata.js- Added F114 to SC 1.4.11 failure techniques listF114 Technique Includes:
Working Example Features:
Testing
The working example allows auditors to:
Impact
Provides auditors with a formal reference (F114) for citing SC 1.4.11 failures when focus indicators are obscured by semi-opaque overlays, filling the identified gap in WCAG testing guidance.