[WCAG 2.2 Draft Feedback] Success Criterion 2.4.11 Focus Appearance (Level AA) #2706
Comments
While I agree with the latter part (“We are also concerned about the overall understandability and testability.”), I am unsure what more research into “contrast, shape, and thickness” would improve the success criterion. The values currently set seem to be an improvement to the existing WCAG 2.1 SCs (“Change one visible pixel”) and feel good as a minimum baseline to me. Of course, focus indicators could be even better than specified, but WCAG just defines the minimum needed. |
|
Proposed response: Requirements
The requirements it is trying to create are based on:
The group itself relies on W3C members to support with research. I believe Google has done some on this topic, could that be shared? I saw a Google presentation a while back on some research into focus indicators that aligned with the SC requirements. The result also lines up with whatever research Microsoft did to settle on a default 1px solid, contrasting outline for Edge (then taken on by Chrome). The specifics also derive from what is available to authors. As mentioned, bigger and more contrasting are better, but where do you draw the line? Research will show it is a continuum (like target size) so we have to draw a line somewhere. If you take the starting point of a contrasting 1px outline (which appears to match Google & Microsoft's research), the rest flows from that.
The first part of the SC is the "easy to understand but inflexible" part. The second allows some flexibility for indicator designs which do appear reasonably visible, but do not match the outline approach.
Because not all indicators are typical or reasonable (from the previous comment). It is trying to improve the current situation where a 1px change (not a 1px outline, a 1 by 1 pixel square) passes 2.4.7. From the document:
That is not the case, it still needs to meet the change of contrast bullet. See examples 4 (1px) and 5 (2px) in test page 3. I'm not saying that's an ideal indicator, but within the contrast principles it allows this to pass: The blue and red don't contrast with each other (noting the red does contrast with the white pixels it is replacing). With at least 2px thickness, it is reasonably visible whether it is black:black (the test page) or blue to red.
That is not the case, the first bullet underneath "An area" specifies how large an area that needs to be. If it were "the area" it would mean the whole indicator, and that would mean all fading/halo style indicators fail, even though they have "an area" that passes. User-agent exceptions
and
and
If the author hasn't changed the foreground or background colors (of the indicator, component or page), then the default indicators should be reasonable. We've only found issues when the author has changed something. Authors can change the indicator, or they can leave the default and change other attributes of the link/button/control. When the author has changed the background (to the component or of the component) there are several scenarios (see test page 6) where changing the background will hide the focus indicator. That is why the exception talks about the background. MiscRegarding the blinking cursor:
Default text inputs also have an outline, but some sites remove it. A task which we are undertaking shortly is a survey for testers to check the inter-rater reliability. |
|
Thanks for the responses. I will respond more detailed next week, but wanted to share an update that we've been working on obtaining approvals to present our research. Would we be able to repeat the approach used for Shadows & Outlines/NTC (attend an upcoming meeting, present the research, and discuss?) |
while on its face the response here makes sense, I'd caution that pretty much all major sites/pages out in the wild will have explicitly set their foreground/background colors (at least for the whole page/document/body). In essence, this would mean that you can never rely on the default UA focus appearance unless you left your HTML completely unstyled? |
|
@patrickhlauke |
|
the only logical conclusion would be to remove the exception? which then means authors are always on the hook to provide custom focus styles? don't see any way around this, unless we lean heavily into "it's the browser's responsibility to sort out a sufficiently visible default outline" in terms of contrast, and somehow pivot this to "unless authors apply styles that interfere with the outline (e.g. some weird |
|
How about if the authors style (e.g. white background) aligns with the default, that is considered a pass via the exception? |
|
can you guarantee that white is the default though? is that explicitly defined anywhere (i.e. that all user agents must use this as the default in their default browser styles)? i remember back in the early days of the web, the default was that awful gray... and of course, it may also be quite arbitrary... if my background is exactly |
|
'guarantee' might take some research. I can say that I have a stock html page I use for testing a lot of things, and it has a white background in every browser I've ever opened (in the past 5 years). |
|
i'd honestly prefer "guarantee" to empirical evidence, otherwise we're building on potentially shifting sands... |
|
I'm not sure we have to quantify what the default is. "If the author's background-color style matches the browser default..." |
|
Perhaps a simple normative language change may allow this to be specified and explained in the Understanding document.
To:
|
|
this feels like you're leaving this an exercise to the reader to work out whether they're compliant or not... also, what happens if there is a browser out there (or gets released in future) that makes the decision that to avoid super-harsh contrast on unstyled pages, they'd rather go for a different default than white? maybe they decide to just start off with a dark theme when no styles have been set? and if we do lean on "what browsers do by default", then what about the trend for many browsers to now adopt a default two-tone white/black focus outline by default that will always work regardless? if there's sufficient critical mass of common browsers ("in widely-distributed user agents") that do this, does that then obsolete the contrast aspect altogether? |
As it is for every SC :)
Speaking practically, if that occurred, I would need to put in my ACR as a comment for this SC "Meets by not altering the browser's indicator and its background colour. Browser X, version ## will not meet this requirement in the following situations due..." |
Yes, just like Resize text. The ideal here is that browsers will continue that trend and folks will achieve this 'for free'. That is stated in the understanding document now:
In an enterprise environment where the browser can be subscribed, a good browser indicator would allow a team to achieve with that now. |
|
This all sounds very brittle, with shades of "Until user agents..." - without a clear indication of what the tipping is when authors can rely on the UA to do things correctly (i.e. when are there sufficient "widely-distributed user agents" that would take care of having a default focus indicator that always has good contrast). and would an author (and later on, an auditor) have to effectively test every possible browser on the market at that specific point in time to determine if a site passes or fails if it relies on just the default focus outline... |
To be clear, IF you both do not alter the background-color style and do not use CSS focus alterations, you can pass with user agent right now. You don't need to test, etc. If you start fiddling with those values, you risk making the browser defaults worse, and you need to test. Generally speaking, if you do decide you're overriding the default focus indicator, it seems reasonable that you do due dilligence -- to the degree anyone checks anything they do on a page across a host of browsers in different markets. That doesn't seem to be anything new. My experience is that most teams are altering the focus indicator and are testing against common browsers. I assume the variety of browsers tested varies markedly -- as it always has, depending on the thoroughness of the teams. |
realistically, show me a modern website these days that doesn't at least set a baseline background colour (even if they set it explicitly to white or off-white). so this seems like an edge case scenario at best (as mentioned earlier in the thread, it's then basically an empty exemption that practically never applies). i vaguely even seem to remember some advice (back from WCAG 1.0 days?) that said do not set foreground colour unless you also explicitly set background colour, exactly for the reason that you may not be in control of how the user agent (or user styles on top of that) will render things. |
|
so perhaps, the way out is to avoid the whole argument about "if you don't change styles, you get away with default focus indicator" altogether. then in understanding, still keep the explanation about modern browsers and how their default styles improve constantly etc, but that authors that rely on just defaults must test in all common browsers/environments if they want to rely on this to pass. which, the more i think about it, the more comfortable i'd be with. rather than setting some form of arbitrary "only if you don't tweak styles", "only if you define the same colours as the 'default' even though this is not specified explicitly anywhere so just use empirical evidence", and similar, you're just focusing on the actual ask (sufficient contrast). if an author wants to claim just relying on default styles passes, then they're on the hook to test this and demonstrate it's actually the case (for all target browsers/environments that they need to consider) |
I've provided language which I think addresses this (to a degree). I'd add that many teams these days are offering themes. Do you not agree they should take some responsibility to make sure their themes result in good focus indicators? The user agent exceptions were added to allow folks to claim compliance using defaults. I think we're both happy those exist? I'm not sure I'm understanding how you want to alter this. Can you provide wording you're suggesting? PS I think these last comments crossed in the ether. I'm not sure I understand what you are proposing when you say "avoid the whole argument" |
It is no advice but a failure in WCAG 2.0, 2.1, 2.2, SC 1.4.3 and 1.4.11:
|
|
Hold on, that's the opposite of what @patrickhlauke was talking about. @JAWS-test you are citing a situation where it is a failure of text contrast if someone specifies a background colour without specifying a text colour. In other words, that guidance does not contradict the notion in Focus Appearance. In fact, not specifying the background color allows you to better pass all those SCs. I just want to make sure we're specifically talking about the same thing here. Also note that in that same section, it states:
So we also have something of a precedent going back to 2.0 implying that white is assumed to be the default background-color. I'm not saying this isn't a tough situation to make consistent. Just that we need to be very careful to compare apples to apples. |
Getting back to this though, the difference here is that the normative wording for resize text doesn't include any specific wording about the mechanism that a page must have. Compare this to the current second bullet exception
When browsers do adopt more universal focus styles (like the double white/black outline), this normative wording will still mean that authors can't rely on them "for free" as it's only exempt if the indicator and the background haven't been modified? unless you mean that when browsers do adopt better focus indicators, you as an author/auditor would just evaluate them against the actual requirements, and not have to rely on the exemption in the first place? in which case, the exemption might actually be confusing, as an author/auditor may not realise that they can evaluate the browser's focus indicator against the actual requirements and skip that bit of the exemption entirely... does that make sense? so perhaps the point that if an author relies on the default focus indicator (even if they have styled their backgrounds/etc), they need to make sure to evaluate against all requirements and test this is all current "widely available user agents", unless they have not changed the styling/background |
|
Many of the existing 2.0 SCs would not pass the level of scrutiny and exactitude imposed on the 2.2 work (if reviewing them in order, you won't make it past 1.1.1 without realizing problems). So Resize text contains the following info in the Understanding document:
We were asked to add an explicit statement in the normative text in Focus Appearance for user agents. So you can see how we've moved from very generic normative text on Resize Text with a bunch of non-normative context on user agents given in the Understanding doc. Folks don't want to do that anymore. So we end up in these contortions. I don't have an answer for that. @patrickhlauke @alastc Maybe it's important to highlight that the wording in the normative text is not changing the page's background-color value. It is:
Can we leverage that nuance? Maybe add in a clarification in the Understanding document along the following lines: "If the indicator's background is modified by the author to the point that a default indicator that passed 3:1 contrast no longer achieves 3:1 with its background, the author cannot meet this requirement via this exception." |
|
We could even make it explicit in the Understanding document that changing the |
we're probably overcompensating, with the hindsight of knowing how vague SCs created 14+ years ago have been causing pain due to their wooly ambiguity... |
|
to be pedantic...
is perhaps not correct. it's the background color that the indicator is placed over (which yes, is not necessarily the page background), not the background of the indicator... |
|
As you say, it isn't necessarily the page background, or even the background of the component, sometimes it is the component itself. I couldn't think of anther way of saying that, without getting into "the pixels that the indicator is replacing" |
|
You might try
"pixels the indicator is covering or replacing"
That gives a better mental picture of what you are talking about. Replacing pixels will be confusing by itself to many people.
… On Feb 8, 2023, at 9:01 AM, Alastair Campbell ***@***.***> wrote:
As you say, it isn't necessarily the page background, or even the background of the component, sometimes it is the component itself. I couldn't think of anther way of saying that, without getting into "the pixels that the indicator is replacing"
—
Reply to this email directly, view it on GitHub <#2706 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXWQQT65GKXBFXID73DWWPGORANCNFSM6AAAAAAQ5DFIVQ>.
You are receiving this because you are subscribed to this thread.
|
|
Yesterday the group approved the response above: If anyone wishes to progress the discussion on the exception and background colours, please open a new issue/PR. |
attempts to address comments circa #2706 (comment)
|
@patrickhlauke, have a look at the first (and currently only) commit in my draft PR #3017 |
|
I have made some minor changes to the understanding document to re-enforce some of the comments in the response to this issue. They are are in #3017 I am adding a Ready for Survey label to ensure that gets looked at, and reopened the issue so that that PR is noticed. @alastc, as soon as it is brought into a survey, this can be reclosed. I am going to undertake a separate PR in which I will propose a minor normative change to address both @dshoukry's questions about the user agent exceptions and those of #3016 |
|
Thank you for continuing to refine the SC. We obtained the approvals to share our research findings, should we coordinate offline to discuss logistics to attend and present those at an upcoming meeting? |
|
The PR @mbgower mentioned is in the survey, so I'll close this again. |
“Success Criterion 2.4.11 Focus Appearance (Level AA): When the keyboard focus indicator is visible, one or both of the following are true:
The entire focus indicator meets all the following:
An area of the focus indicator meets all the following:
Exceptions:
Recommendation:
Similar to our previous rounds of feedback, we kindly request that the group remove this SC until research is completed for the specifics around contrast, shape, and thickness of the indicator as specified in the SC. We are also concerned about the overall understandability and testability.
From the last responses in our Github issue:
This is all likely so, but there should be research to quantify the pixel and contrast minimums.
If the current indicators are reasonably clear and pass the current SC text, why is this SC needed and what is the issue we are trying to solve/improve?
Additionally, the first exception (“The focus indicator is determined by the user agent and cannot be adjusted by the author”) implies that if the browser fails this, then the content authors must fix it. This conflicts with other guidance like "1.4.13 Content on Hover or Focus". We are concerned about the approach of making content authors responsible for fixing user agent issues, and would propose changing it to "…by the user agent and is not modified by the author".
Ultimately, this seems like an especially important area to have research, a diverse set of use cases, and a specific set of content structures to keep the SC beneficial, appropriately scoped, and attainable.
Please find detailed specifics covered in our Sep22 2.4.11 Focus Appearance (AA) Google Doc
The text was updated successfully, but these errors were encountered: