Focus-appearance and Non-text-contrast relationship

[alastc]

During the group discussion on 27th Oct there was discussion (triggered by #1403) about the need for the 3rd bullet:

Adjacent contrast: The focus indicator contrasts at least 3:1 against all adjacent colors, or has a thickness of at least 2 CSS pixels.

The question was: Do we need this consider non-text contrast overlaps?

(Chair hat off now)

We've had quite a few discussions & resolutions on Non-text contrast since WCAG 2.1 was publish, picking a few relevant ones:

---

The understanding document states under Adjacent Contrast:

"For user interface components 'adjacent colors' means the colors adjacent to the component. For example, if an input has a white internal background, dark border, and white external background the 'adjacent color' to the component would be the white external background."

Then from the relation to 2.4.7 section:

"In combination with 2.4.7 Focus Visible, the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused, except ... If the focus state relies on a change of color (e.g., changing only the background color of a button), then changing from one color to another that has at least a 3:1 contrast ratio with the previous state of the control is a method for meeting the Focus visible criteria."

Those changes came from issues like:

• Clarify in understanding whether SC 1.4.11 Non-text contrast adjacent colors requires both sides of adjacent colors or only one side have sufficient contrast #540, “each state of the component must have contrast against the non-component adjacent colors, but not within the component.
• Non-text contrast updates #550 which says "if the focus indicator adds/removes parts of the component, or changes the shape of the component, that change must have contrast. (e.g. adding thickness to a border that has contrast, or adding a separate outline.) However, it doesn't have to contrast with itself if it changes the shape."
• 1.4.11 seems to include the ACTIVE state of links and buttons. #517 / Does SC 1.4.11 require comparing focused and non-focused states #541 prompted PR Remove misleading/incorrect statement from 1.4.11 understanding #1058 which was agreed in August and this survey. "Note that this Success Criterion does not directly compare the focused and unfocused states of a control - if the focus state relies on a change of color (e.g., changing only the background color of a button), this Success Criterion does not define any requirement for the difference in contrast between the two states." (Not appearing in the docs yet, probably delayed due to the work on Silver.)
• The minutes from 2018 where we resolved that 1.4.11 doesn't apply to internal states.

My argument is that Non-text contrast only measures "adjacent colors" outside of the component, therefore it is not suitable for focus-styles. We cannot ask for Non-text contrast to apply to both the component against the "background" (adjacent colors to the component) and the focus-indicator with the current language. (Particularly as it applies to all 'states', so doesn't differentiate from hover etc.)

That is why we approved in August this addition to the understanding doc:

"if the focus indicator adds/removes parts of the component, or changes the shape of the component, that change must have contrast. (e.g. adding thickness to a border that has contrast, or adding a separate outline.) However, it doesn't have to contrast with itself if it changes the shape."

So my proposal is that in WCAG 2.2 we remove the overlap from 1.4.11 and rely on the new SC to cover focus styles (leaving the 2.1 version of non-text contrast as it is).

I proposed updating the 3rd bullet to match the one above, so the complete SC would be:

When user interface components receive keyboard focus, all of the following are true:

• Minimum area: The area of the focus indicator is at least as large as as the area of a 1 CSS pixel thick perimeter of the focused control, or the focus indicator has a thickness of at least 8 CSS pixels along the shortest side of the user interface component.
• Change of contrast: The pixels making up the minimum focus indicator area achieve at least a 3:1 contrast between their colors in the focused and unfocused states.
• Adjacent contrast: The pixels making up the minimum focus indicator area achieve at least a 3:1 against all adjacent colors, or have a thickness of at least 2 CSS pixels.
• Not fully obscured: The item with focus is not entirely hidden by author-created content.

Also, during the discussion we were wondering about the adjacent colors when it comes to, for example, a contrasting outline that also has a halo around that, e.g.

(Codepen for the source code)

In this case the orange outline meets the first two bullets and contrasts with the button itself. However, the presence of the yellow halo means it is not contrasting with all adjacent colors.

I propose that we tackle this in the understanding, in a similar way we have in non-text contrast:

"If components use several colors, any color which does not interfere with identifying the component can be ignored for the purpose of measuring contrast ratio. For example, a 3D drop-shadow on an input, or a dark border line between contrasting backgrounds is considered to be subsumed into the color closest in brightness (perceived luminance)."

So for focus-appearance, that would be something like:
"If the focus indicator uses several colors, any color which does not interfere with identifying the indicator can be ignored for the purpose of measuring contrast ratio. For example, a 3D drop-shadow on a focus indicator is considered to be subsumed into the color closest in brightness (perceived luminance). If the size is uncertain, calculate the minimum size based on the area which meets the contrast change requirement."

[ghost]

For what it's worth, I'm in favour of any streamlining or simplification to the Non-Text Contrast issue.

Regarding this quote...

So my proposal is that in WCAG 2.2 we remove the overlap from 1.4.11 and rely on the new SC to cover focus styles (leaving the 2.1 version of non-text contrast as it is).

Would you leave in hover state in the WCAG 2.2 interaction of 1.4.11?

[alastc]

@wardav hover is more or less removed from 1.4.11 already:
"For example, there is not a new requirement that visited links contrast with the default color, or that mouse hover indicators contrast with the default state. However, the component must not lose contrast with the adjacent colors..."

[DavidMacDonald]

If I understand correctly the current 3rd bullet is being proposed to address the possibility of a focus ring that is similar in colour to the button and therefore when the focus lands on that component, the indication of focus is more subtle, and may be difficult for some to see.

My concern is the following

1. the cure may be disproportionately difficult to the benefit. I understand from the call last week that a technique that could be given prominence would be to have two focus indicators that are 2px each and depending on the colour of the the control the dev would choose the dark or the light one. This requires devs to know every button on the site and make a conscious choice for each component.
2. The idea of a global 2 colour focus indicator which we have been providing since 2.1, would no longer be sufficient. The difference between these two techniques (a 2 colour indicator vs two different indicators) could represent many hours of sifting through the site to identify buttons and choose them. Some of that might be automatable but that wouldn't be trivial.
3. The AGWG has been given a mandate to make WCAG.next easier to understand, and this SC is very complicated with the 3rd bullet. I would propose that it is more complicated that any other of the success criteria in WCAG 2.0, 2.1 or 2.2.
4. Any success criteria that impacts the visual design needs to be vetted very carefully because historically they have come under greater scrutiny and criticism from stakeholders.
5. The primary group of people that this will help could end up being testers rather than users. Because the characteristics that make this the 3rd bullet important for accessibility are an combination of factors (2 disabilities, button colour and inside focus indicator combinations). If there is a two colour focus indicator the user will usually know where they are although the odd control might be subtle. I have a blog article on keyboard use patterns in the wild.
6. There has been significant progress in browsers on this issue lately and the way they are addressing it is via a two colour control which we have been promoting. With this success criteria we are essentially saying, "sorry, that's not the right way to address this."

[JAWS-test]

@DavidMacDonald

The idea of a global 2 colour focus indicator which we have been providing since 2.1, would no longer be sufficient.

If you mean the C40 technique, I don't know why it should no longer be valid. Only the size of the indicator might have to be adjusted, but the technique itself is still good.

Just because 2 colors are used, the 3rd bullet is not relevant for C40.

By the way, the fact that the size of the indicator may need to be adjusted also applies to all other focus techniques.

[DavidMacDonald]

@JAWS-test
I believe that if the 3rd bullet stands then a 2 colour indicator would have to be 4px wide (2px light, 2px dark) which is would create a significant impact on the visual design.
If there is a black button and a two colour black/white focus indicator 1px black 1px white, with the black on the inside, then we have a failing situation under the current 3rd bullet.

[alastc]

The update to the 3rd bullet from today (merged) is:

The pixels in the minimum focus indicator area achieve at least a 3:1 against adjacent colors in the focused control or the minimum focus indicator area has a thickness of at least 2 CSS pixels.

The impact that has really depends on your background colours, if they are all light(ish) or dark(ish) then it's pretty straightforward.

If you want to see the example from the meeting, open this codepen in Edge (or Chrome if that's updated as well).

As an example, this is essentially a triple colour indicator (light/dark/light) that works across both backgrounds.

The key code from that is:
box-shadow: 0 0 0 1px white, 0 0 0 2px #000, 0 0 0 3px white !important;

But you don't have to do that, you could use:

• A custom 1px indicator for a light background, and a different one for the dark background. If you have solid light and dark controls on both backgrounds, add outline-offset: 1px (so it's slightly separated from the control).
• A custom 1px indicator for a light background, and a different one for the dark background. If you have solid light and dark controls on both backgrounds, make it 2px thick.
• A 2px outline with outline-offset: -2px (so it's within the control), e.g. the main nav here.
• A Gov.uk style thick underline + yellow (non-contrasting) background change.
• A background change.

Personally, working with design teams I've had the best success with the approach of: one for light backgrounds, one for dark backgrounds.

[alastc]

Closing this issue as it was discussed during the meetings and we merged in the proposed changes.