Focus obscured and semi-transparent/blurred overlays - reword, and DO make it fail at AAA#4824
Open
patrickhlauke wants to merge 1 commit intomainfrom
Open
Focus obscured and semi-transparent/blurred overlays - reword, and DO make it fail at AAA#4824patrickhlauke wants to merge 1 commit intomainfrom
patrickhlauke wants to merge 1 commit intomainfrom
Conversation
Initially, this PR intends to reword the explanation of what "light boxes" are, which is currently quite confused/confusing (or rather, it talks about light boxes while actually referring to the semi-transparent overlay that usually accompanies them) - as the conversations in #4673 started to veer off at a tangent because of it (as it seems some folks thought "light box" equated to glass/blur type effects). This PR rewrites the section to hopefully be clearer and more direct. However, from the discussion, it seems clear that some folks would argue that focused components that are covered somehow, even by a semi-transparent only overlay, do normatively fail the requirements of componanent having "no part [...] hidden". While for AA it's probably ok to be lenient and handwave that components aren't *entirely* hidden when behind such overlays, it gets more difficult to justify for the stricter AAA "no part" requirement. /cc @scottohara
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Member
Author
|
Note that this proposed change in the AAA understanding DOES effectively change the normative interpretation for this SC, so will need careful consideration. To take it to the extreme though, I can't imagine justifying a component that is completely covered with a 99.99% opaque overlay, or a super-strongly-blurring overlay, having "no part [...] hidden", when they can barely be seen/discerned. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Initially, this PR intends to reword the explanation of what "light boxes" are, which is currently quite confused/confusing (or rather, it talks about light boxes while actually referring to the semi-transparent overlay that usually accompanies them) - as the conversations in #4673 started to veer off at a tangent because of it (as it seems some folks thought "light box" equated to glass/blur type effects). This PR rewrites the section to hopefully be clearer and more direct.
However, from the discussion, it seems clear that some folks would argue that focused components that are covered somehow, even by a semi-transparent only overlay, do normatively fail the requirements of componanent having "no part [...] hidden". While for AA it's probably ok to be lenient and handwave that components aren't entirely hidden when behind such overlays, it gets more difficult to justify for the stricter AAA "no part" requirement.
/cc @scottohara
Previews: