You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> Should (Enhanced) version be so tolerant of opaque overlay?
Actually, @bruce-usab, on re-reading the Enhanced normative text, I do not believe that a lightbox should be considered to fail this criteria. The language does not use "obscured", it uses "hidden".
no part of the component is hidden by author-created content.
I don't think we can make the case that dimming something hides it. Even in the minimum version, we don't say the lightbox is failing Focus Not Obscured. We say it is likely to fail 2.4.11 Focus Appearance.
On rereading that part of the Minimum understanding document, I have some changes to suggest.
Given that 2.4.11 is now a AAA, my feeling is that the language in the minimum should actually point to Non-text contrast, and
That gives us something appropriate to assess at each of the levels. If you agree, can you alter this PR to support that?
As part of that, you will need to remove this commit: 61dcd0c
At that point, the language for Enhanced seems fine for lightbox (assuming the link points to the AAA version of Focus Appearanced). The AA version would need to be updated.
The text was updated successfully, but these errors were encountered:
bruce-usab
changed the title
> Should (Enhanced) version be so tolerant of opaque overlay?
Focus Not Obscured (Enhanced) should permit opaque overlays
May 16, 2023
Per Tuesday call, I am opening this new issue rather than adding/editing PR #3163
As @mbgower notes above, SC 2.4.12 reads (emphasis added):
When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.
The SC text clearly implies covering up or entirely hiding part of the component (with focus indicator). A (much less desirable) alternative is to tweak the SC text. That might look like:
When a user interface component receives keyboard focus, no part of the component is obscured by author-created content.
To be clear, Focus Not Obscured (Minimum) is fine as-is). The issues with 2.4.12 is that there is a tension between the non-normative name/label for the SC and its normative SC text.
Actually, @bruce-usab, on re-reading the Enhanced normative text, I do not believe that a lightbox should be considered to fail this criteria. The language does not use "obscured", it uses "hidden".
I don't think we can make the case that dimming something hides it. Even in the minimum version, we don't say the lightbox is failing Focus Not Obscured. We say it is likely to fail 2.4.11 Focus Appearance.
On rereading that part of the Minimum understanding document, I have some changes to suggest.
That gives us something appropriate to assess at each of the levels. If you agree, can you alter this PR to support that?
As part of that, you will need to remove this commit: 61dcd0c
At that point, the language for Enhanced seems fine for lightbox (assuming the link points to the AAA version of Focus Appearanced). The AA version would need to be updated.
Originally posted by @mbgower in #3163 (comment)
The text was updated successfully, but these errors were encountered: