For reference: there is AG WG discussion in a mail list thread

[Official WG Response]:

@goetsu
For context, please take a look at the updated SC text. The Working Group has not changed its interpretation of this SC but in response to comments and questions has updated the text to better reflect the WG's intent.

SC text:
https://w3c.github.io/wcag21/guidelines/#non-text-contrast

https://www.funka.com/en/ :
contrast of the search field against grey background of the header isn't compliant
contrast of the bottom border of most of the news isn't compliant with white background

The search button at the top is identified by text (>4.5:1) and an image (>3:1) and this is viewed to be sufficient by the Working Group.

https://www.statefarm.com/ :
contrast of active state of the menu button when the menu is open again the red background isn't compliant

The Working Group views the White text and "X" for the menu button to be sufficient to identify the button/link to activate.

contrast of zip code input border (light grey) against white isn't compliant
Can't find this example, but if there is a form input it would benefit from the border.

http://adrianroselli.com/2018/02/github-contributions-chart.html
contrast of border of navigation item (dark grey) against black isn't compliant
The WG views the navigation items to be identifiable through gestalt information and the white text on the black background is sufficient.

https://knowbility.org/
contrast of the burger icon (mobile version) background against white background isn't compliant

The menu graphic is >3:1 and the combination of the text and graphic makes it sufficiently clear that a control is present to be activated.

http://www.lflegal.com/
contrast of navigation item with grey border against light grey background below them isn't compliant
Same response as for Adrian's site.

https://www.microassist.com/project/viral-load-changes-hiv/
contrast of border of navigation item inside menu that appear on hover isn't compliant
contrast of border of the search field against white background isn't compliant (neither yellow magnifying glass icon)
The WG views the navigation items to be identifiable through gestalt information and the text/background combinations are sufficient.

Also the understanding document state "the visual boundaries of the component must have sufficient contrast with the adjacent background" I think it must be "the visual boundaries of the component must have sufficient contrast with the external adjacent background on all sides of the component"

The Working Group did not intend for this interpretation. It is possible for controls without any borders to conform as long as the control can be identified and the approximate clickable region can be identified.

the new SC text is better but highly interpretable. It will be painful for testing and to make people understand what they can or can't do but I suppose it's the best consensus you get.

Understanding / definition / example / success criteria and failure must be reworked a lot otherwise I think most people will not understand it and know what pass or fail

The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 3 days. If we haven't heard a response by then we will regard the resolution as satisfactory.

I'm ok for the update of the SC but the understanding document is still very perfectible :

• no mention of the gestalt exception used to validate most of my example
• still no clear indication that hover state must be covered by this SC (cf SC 1.4.11 contrast on hover included or not  #913)
• some part still rewrite specialy

any visual boundary that indicates the component's hit area (the region where a pointer can activate the control) must have sufficient contrast with the adjacent background

and

This success criteria does not require that controls have a visual boundary indicating the hit area, but that if there is an indicator then it has sufficient contrast.

I propose something like :

any visual effects (border, background, outline, ...) that can't be removed without loosing indication of the component's hit area (the region where a pointer can activate the control) or indication of the component's state must have sufficient contrast with the adjacent background

and

This success criteria does not require that components have a visual effect indicating the hit area or state, but that if there is a visual effect that necessary to determine the hit area or state then it has sufficient contrast.

@goetsu Great - I'm working on updates for the Understanding document and have marked this issue with the "Implementation follow-up" label so we will keep it in mind when updating the understanding document.