Exception for native controls failing 1.4.3 Contrast (Minimum)?

[detlevhfischer]

We have a discussion whether in testing text contrast, it is OK to exempt native controls where contrast is insufficient, for example, in Chrome native selects and the Chrome native calendar widget.

I think it is uncontroversial to blame user agent developers here.

I think it is equally uncontroversial that it is generally better to recommend the use of native controls where they exisit rather than forcing delevopers to create custom controls that may meet contrast requirements but are likely to have other gaps in support (and are more brittle, time-consuming, may have issues with custom colors, require JS and potentially fallbacks, etc).

@mitchellevan makes the case that in a site audit, content like Chrome selects and date pickers should fail 1.4.3, and the audit report and/or accessibility statement should then point to UA makes as culprits. The argument is that this would increase pressure on UA makers to get their act together.

Our line so far is that an audit that focuses on web content and its authors can justify a PASS rating for 1.4.3 where native controls have insufficient contrast but all other content meets 1.4.3, possibly pointing out that contrast issues in native controls are a UA bug to be rectified there.

What do other people think?

[patrickhlauke]

The argument is that this would increase pressure on UA makers to get their act together.

this argument seems...idealistic, considering that in many cases UA makers have been shown not to care too much. also, how does "punishing" individual site owners (i.e. nominally telling them they fail WCAG / noting this in their ACRs) put pressure on UA makers?

while it's true that an end user doesn't distinguish whose fault a problem is, only that it is a problem, for the binary pass/fail report aimed at content authors, it's worth being a bit more nuanced ("in practice this fails, but it's due to something beyond your control")

[JAWS-test]

Duplicate of #3013

[mitchellevan]

I agree it's idealistic, but "it's normative WCAG" by itself seems not enough to convince the country-wide authority for Germany. I'm trying to give them a way to reconcile WCAG with the regulatory constructs of WAD and BITV. BIK-BITV/BIK-Web-Test#317

[detlevhfischer]

Thanks @JAWS-test for the reference back to your issue - I was looking for previous issues but it seems not thoroughly enough.

[detlevhfischer]

Focusing on the select, to keep this normative fail in perspective, there are also some mitigating aspects to keep in mind:

• the unselected options have very strong contrast
• the contrast of the background to the white text of the selected option is 3.2:1, so while clearly falling behind the requirement of 4.5:1, it is not a desaster (side note: it seems to meet the APCA contrast proposed as future alternative for WCAG 3, if I interpret it correctly)
• arrowing through the select options without expanding the select shows the currently selected option in strong b&w contrast
• it is easy to see the option with its strong default contrast when focusing adjacent options (mouse or arrow keys)

So I would argue the practical impact on users of the selected state failing 4,5:1 is relatively minor. (I know this is a slippery slope but I thought I'd say it anyway).

[patrickhlauke]

the contrast of the background to the white text of the selected option is 3.2:1,

side note: this also means that the contrast of the background of the selected/focused option, versus the white background of the non-selected option, will satisfy 1.4.11 (and the upcoming focus appearance SC) ...

[mitchellevan]

@detlevhfischer, I'm closing this issue as duplicate of #3013. If that was incorrect, please reopen it.

[JAWS-test]

@mitchellevan #3013 was just a discussion, this is an issue (of higher priority, I suspect). While discussion just fizzles out, issues need to be fixed, right? Maybe it's better to leave the issue and close the discussion.

[mitchellevan]

Reopened