2.4.7 Focus Visible - what counts as "visible"? #302
Comments
|
I agree with @patrickhlauke In the Abstract and Background, WCAG states the importance that SCs be testable:
In terms of "Focus Visible", it would go a long way for understanding conformance if a definition of "visible" was provided. In practice we see many well-meaning developers providing a focus indication that is likely to be difficult or impossible to discern for the reasons Patrick mentioned. |
|
The interactive components contrast SC is intended to cover focus indicators. Assuming you saw that, did it not appear to cover focus indicators, or would you still rather see visible better defined? |
unless 2.4.7 then cross-references that SC (ideally normatively), it still leaves this SC's vague language in place. And as the SC will be looked at in isolation, it'll still be a problem. |
|
In short, even if this SC really means "visible" as a binary "there is or isn't a focus indication", it should (at the very least in the understanding doc) define clearly what "visible" means. Even if it simply needs to say that, in broad terms, ANY styling change/visual addition/etc counts as "visible". |
2.4.7 passes if the author doesn't remove the focus indicator... theoretically it would fail if the author created an outline of no width and with no colour but I've never seen that. The only failure I see is removing focus indicators. We may want to merge 2.4.7 with the new SC. That's on the table. The Interactive components SC should make it clear focus indicators are covered. I made a recommendation early on that has not been adopted. I think we'll have to cycle back and I agree we need a cross reference in the normative document. There is lots of precedence for that already in WCAG 2.1 |
|
Speaking theoretically, a very strict reading of the normative text would mean that, in an extreme case, if focus introduces a single pixel change on screen, right at the limit of what can be represented (e.g. on a white |
|
I have opinions on this. I think the SC should consider default focus styles when identifying a pass/fail. I have said as much in other issues. I'll just leave this example here where the Chrome default focus ring is the same color as the page background: https://codepen.io/aardrian/pen/WxEbrg |
|
@aardrian problem there is that it's arguably a UA issue/responsibility/failing. the browser should, if the defaults are not messed with by author CSS, do its job properly... |
|
@patrickhlauke Yes this is right... there is no requirement on "how" visible it needs to be under 2.4.7 in WCAG. There were long passionate discussions during WCAG 2 about this. But that is water under the bridge. I'd like to explore merging with the new SC. |
|
During a WCAG2.1 discussion get-together we had on the 10th of January, this issue came up-- that the clear exception for user-agent-authored in 1.4.11 ("except where the appearance of the component is determined by the user agent and not modified by the author") could fall back to hit 2.4.7 where it hadn't so explicitly before. |
|
I don't think it is much of a loophole, if the appearance of the component is unchanged by the author, it would be default text links or default buttons. Do you come across that much? I haven't, it is almost always that links & inputs have been styled, and the outlines have been removed (we fail on 2.4.7 a lot). So the recommendation is to replicate the mouseover styles or allow the default outline, which is what most people then do. |
|
going back to the "what is 'visible'" angle - is 2.4.7 going to be subtly extended to cross-reference 1.4.11 (either normatively or in the understanding doc)? |
|
It would have to the understanding rather than SC text, but I can't see a problem with adding something there. E.g. at the bottom of the last paragraph in the 'intent' section, focus indicators should meet 1.4.11. |
We (the designers at work) allow the default outline. Then we (the accessibility QA at work) fail the dev teams because it's often not very visible (depending on user agent, all the examples Pat mentioned earlier like blink's blue when the focusable is on a blue background area). That's because our internal QA goes by "can WE see the outline" rather than "can a computer measure an outline exists". In the discussion group we wanted that IF authors changed something in the general link/button/whatever style, that this should ideally mean they need to manually check or add in focus styles. |
|
@StommePoes i think the end result of the discussion here is that wcag 2.1 will keep this flawed / very vague SC, but cross-reference the tighter 1.4.11. so those too-subtle focus indicators will pass 2.4.7 BUT fail 1.4.11 |
|
I'm not sure I'm entirely following, but I suspect there is a gap in the changes of state, e.g. default to focused. I don't think there is anything that says those two aspects need contrast, which is in discussion here. The question for me is does changing the background count as changing the default appearance of a link? (I.e. the background of a parent element, not adding a background to the link.) If so it's covered, if not then it is a bit of a gap but not sure we can fill it. |
|
I'm hoping this is the correct issue for my question as it relates to what is "visible". I'm currently working on projects where main brand color is almost identical to the blue focus ring that Chrome uses for interactive elements. If we leave the focus ring untouched then, as I read the current success criteria, we would pass because we're using the browser's default styling, even though it's almost impossible to see the focus ring. This seems to be a problem of both Focus Visible and Non-text Contrast criteria. |
|
@fstorr it would pass 2.4.7 (as 2.4.7 really just says "visible" without defining any other parameters), but fail 1.4.11. if you left it untouched/unstyled, then it's up to the user agent to provide a clearly contrasting/visible focus indication. if you explicitly define it yourself, then it's your responsibility, and therefore your failure, if the contrast is too low. |
|
It's as if we need another set of "standards" called Practica11y which is based on arguments such as "while doing x technically meets WCAG, the end result is obviously useless for real humans" with recommendations similar to the Techniques in WCAG. It would tackle things like "default browser focus is useless with these branding backgrounds", "box-shadow/background-color/border-color changes to show states is invisible in WHC", "z-indices of custom control images interfere with speech recognition" etc. Problems are: Yet M0aR Standards/Drowning In Standards and No Authority (as much as WCAG doesn't have a lot of actual authority, it's an easy thing for organisations to use as a goal and act as though it's an authority of some sort). But it could be similar to how people decide whether to shoot for AA or AAA, I suppose. "We meet WCAG AA and the Practical Accessibility Techniques list" or something. |
the problem is quite complex here. in part, it's due to not having been able to actually go in and fix old WCAG 2.0 SCs (to make those backwards compatible). as for browser defaults, we'd then need to constantly keep it up to date based on what different defaults browsers use, what heuristics they use, etc. not a sustainable model. browsers should really provide accessible defaults / follow UAAG. but hey... for developers, what's really needed is for them to not try to just meet WCAG, but to see it as a lowest common denominator. |
|
Seems like if you modify any part of the visual appearance of the control then you are responsible for the focus indicator and all parts meeting contrast right? Or do others read it that only if you change visual aspect related to focus indicator are you responsible for the focus indicator having sufficient contrast. |
|
@mraccess77 aye, there's the rub. a strict reading of "or where the appearance of the component is determined by the user agent and not modified by the author" would suggest that ANY styling (even unrelated to focus outline...like setting the text color or something similar) would break this. In essence, even changing the background for the whole page could count as modifying the appearance (if it's a link, and it's now not showing on the completely vanilla background colour of a page). or setting a base font on the html element that then affects the appearance of the control. dare i say this is...wooly? does it in effect mean "only in completely unstyled documents"? (i believe this was raised in discussions at the time, but can't remember an authoritative answer on that) |
|
@mraccess77 i'd suggest opening a new issue on this particular aspect. my energy for discussing these types of very fine points is currently depleted... |
|
The concessus position was that we couldn't cover changing aspects with the 1.4.11 wording, so it covers that the component must maintain contrast, but not the change of contrast for focus. No need for a new issue, it is one of the 2.2 SCs to work on, let me know if you want to get involved. |
|
I believe what was agreed upon for the target SC which has similar language is that any visual change to component would trigger it -- but changes to the page background or ancestor elements that weren't inherited would not count and the exception could be used. |
Thanks for this. I read and re-read 1.4.11 before posting here. I got tripped up on this, which I took to mean the just focus styling and not the component as a whole in any state:
|
|
Jon Avila writes:
Seems like if you modify any part of the visual appearance of the control
then you are responsible for the focus indicator and all parts meeting
contrast right?
That has certainly been my argument all along. State indication is *PART*
of the control/component (as opposed to part of the *element*)
Alastair Campbell writes:
The consensus position was that we couldn't cover *changing* aspects with
the 1.4.11 wording, so it covers that the component must maintain contrast,
but not the change of contrast for focus.
I'll push back on that statement, as it was less a consensus and more a
majority vote within the Working Group, and very much came down to
interpretation of a specific sentence. The SC states:
Visual information required to identify user interface components
<https://www.w3.org/TR/WCAG21/#dfn-user-interface-components> and states
<https://www.w3.org/TR/WCAG21/#dfn-states>, except for inactive components
or where the appearance of the component is determined by the user agent
and not modified by the author;
...the argument being that if the author changes the component, but not the
state indication (relying on browser defaults) it cannot Fail, because some
take this to mean that changing the state indication is external to the
component.
However others (including myself) continue to argue that the various states
of any given component are all part-and parcel of that component - that the
key to interpreting the clause is the use of AND (user interface components
AND States) as being a singular, as opposed to two things ( a: the User
interface component, b: the state indication).
I have argued this since the beginning, and will continue to do so, however
I also chose to let it be in the 2.1 time-frame (as the other option - the
nuclear option - would have been to file a Formal Objection, and it wasn't
worth the angst that would bring)
Alastair Campbell writes:
No need for a new issue, it is one of the 2.2 SCs to work on, let me know
if you want to get involved.
Indeed, and I for one will seek to ensure this divergence of opinion and
interpretation is resolved. As Mallory noted "while doing x technically
meets WCAG, the end result is obviously useless for real humans" which I
also read as "...leaving the default focus indicator in Chrome as 'the blue
halo', while used on a component on a similar shade of blue background,
technically meets the requirement, but fails the user..."
JF
…On Wed, Apr 24, 2019 at 10:21 AM Jonathan Avila ***@***.***> wrote:
I believe what was agreed upon for the target SC which has similar
language is that any visual change to component would trigger it -- but
changes to the page background or ancestor elements that weren't inherited
would not count and the exception could be used.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#302 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAJL4462K2HQAO6RYJ6O3OLPSB3I3ANCNFSM4DZQIOUQ>
.
--
*John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
|
|
Sorry, please forgive a short answer, I'm trying to work through the 185 issue backlog at the moment. Let's solve the core problem of defining 'visible', which is best done with an addition :-) |
|
now this is making me wonder...is the " where the appearance of the component is determined by the user agent and not modified by the author" just referring to, say, the state indication i.e. the focus ("if the author has changed the appearance of the component to show the focus"), or the appearance in general, even when not focused (i.e. just a general "this is how links/buttons/etc look in general" type CSS)? |
|
As this issue is on the list of issues to work on for WCAG 2.2, I am closing this issue after adding the "WCAG 2.2" label. We will revisit the WCAG 2.2-labeled items after WCAG 2.2 is done and can reopen issues as needed. |
Arguably, "visible" is not unambiguously defined/testable. A strict reading of just the word of WCAG would indicate that any focus indication is "visible", even if it has far too low contrast, is too thin, is difficult to distinguish somehow.
It would be useful if "visible" could be at least defined a bit more in non-normative understanding documentation - or ideally, if the normative definition of the SC could include clearly testable statements of what does and does not constitute "visible".
The text was updated successfully, but these errors were encountered: