Success Criterion 1.4.11 - Non-text Contrast - Level AA

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#non-text-contrast

Share your thoughts for applying to mobile apps as a comment below.

[qbalsdon]

I think we need to align with the regular guidance, if we take external factors like sunshine into consideration we could be far more prohibitive and not actually very helpful to the end user

[carolinacrespo]

It should be clear that this applies to user agent for the browser and the native iOS and Android widgets

[JJdeGroot]

MATF meeting on July 31, 2024

Source
JJ: Reading text from WCAG2ICT, mentioning the user-agent exception for contrast needs to be mapped to mobile.

+1 to the inactive component exception being problematic.

did we skip 1.4.10 REflow?

<Joe_Humbert> +1 to the inactive component exception being problematic

1.4.10 discussion @jamie: w3c/matf#4

Joe_Humbert: About not modified by the author. This doesn't seem to be defined - what does that mean? For example, if the background colour is changed but not the component, does that not impact the contrast?

Agree with that - thinking about iOS default palette and text styles that don't have sufficient contrast

+1 we should not rely on manufacturers being accessible. We need to hold them accountable too

@JJ we should create a separate ticket about user agent

ACTION: Github issue for User-Agent discussion

Summary:

JJ, Joe_Humbert and Mick find the inactive component exception problematic.

Joe_Humbert: raises concerns about the definition of "not modified by the author" and its impact on contrast, using background color changes as an example. julianmka agrees, noting iOS default palettes and text styles may lack sufficient contrast. quintinb adds that manufacturers should be held accountable for accessibility.

JJ proposes creating a Github issue for user agent discussion.

[Keanem6]

Should we be include requirements for Dark mode as well?

[JJdeGroot]

Example of component which is "not modified by the author"

Light gray: #EAEAEB on white #FFF = 1,20:1 contrast

After enabling high contrast

Darker gray: #96969d on white #FFF = 2,94:1 contrast

This might actually have 3:1 contrast because the screenshot compression reduces the color accuracy by 1-10%
(that's one of the problems with calculating contrast of mobile apps when you don't have source code access)

[JJdeGroot]

A few notes/comments below from e-mail conversation with @alastc (AC)

JJ:
For 1.4.11 Non-text Contrast, there is an exception for components where the appearance is determined by the user agent AND not modified by the author

• Where do we draw the line for components provided on Android and iOS?
• For example, Jetpack Compose is a declarative UI framework which requires developers to add extra dependencies.
• To add Material Design components, you also need to add extra dependencies. Do we still consider these to be provided by the user-agent when they are developed by Google?
• It can be difficult to check whether a component was modified by the author, because auditors usually don't have access to the source code. E.g. it's not easy to "inspect element" to check for CSS like you can do on the web.

AC:
I don’t think any of these would count as provided by the “user agent”, as there isn’t a user-agent involved for native apps (unless something were provided by the AT, such as the bounding box for focused items).

JJ:
And what about native components that are provided "out-of-the-box" by the operating system, e.g. a UISwitch on iOS? The border doesn't have sufficient contrast on a white background.

1. Assuming the high-contrast version has >= 3:1 contrast, would this component pass the requirements, even though high-contrast mode has to be enabled?

2. If neither the normal and high-contrast version have 3:1 contrast, would we pass it when the author has not modified the styling?

3. What if the author has modified the color of the selected state (green color) and not the unselected state (gray color). Would you fail the component because some of the styling has been modified, even though the unselected state is still showing the same unmodified color?

AC:
Regarding the user-agent aspect:

JJ: And what about native components that are provided "out-of-the-box" by the operating system, e.g. a UISwitch on iOS?

There still isn’t a user-agent, this is a native app. A user-agent is an intermediate technology that translates/modifies the interface for the user.

In a native app, the developer puts things together (including, optionally, out-of-the-box components) and sends that to the user. The user gets that software, unmodified by any intermediate software.

E.g. when a web developer puts a select-box on the page, the dev doesn’t control the behaviour (or much of the appearance) of the select-box. It is provided by the browser. I think that’s a different scenario from native.

The complication is that the OS can provide some override / modification, so sort-of acts like a user-agent, but I don’t think we should conflate this situation with there being intermediate software.

1. Assuming the high-contrast version has >= 3:1 contrast, would this component pass the requirements, even though high-contrast mode has to be enabled?

I think you could write guidance to the effect that users who need higher contrast should have that option enabled, and if the components pass in that condition, that could be considered a pass. I just think that’s unrelated to whether it’s an out-of-box component or not.

2. If neither the normal and high-contrast version have 3:1 contrast, would we pass it when the author has not modified the styling?

I don’t think that should pass. The author has the option to adjust the colours or use a different component. Again, components provided by the platform-maker are not the same as a user-agent.

3. What if the author has modified the color of the selected state (green color) and not the unselected state (gray color). Would you fail the component because some of the styling has been modified, even though the unselected state is still showing the same unmodified color?

As above, it should be unrelated to whether it’s an out-of-box component or not. We only put that exception in because in some browsers you can’t modify some aspects of browser-provided components.

[detlevhfischer]

@JJdeGroot @alastc In the EN 301 549 the user agent is defined as the platform for web content in the same way as the OS is the platform for native apps. WCAG2ICT 2.2 also states

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.11, replacing "user agent" with "user agent or platform software".

So I think there is a good case for treating the OS in the native app context as equivalent to the user agent in the web context, and applying the same exception "where the appearance of the component is determined by the user agent and not modified by the author".

However, without access to the source code it is impossible to determine if an element just looks unmodified (but is custom-defined) or is indeed unmodified. The pragmatic approach is then to say, "if it looks like a duck and quacks like a duck..."

One element that is tricky is that to rely on a platform meachanism to improve contrast overall, this mechanism itself would have to meet WCAG (or WCAG2CT here). Without the iOS "Increase Contrast" setting made, the switch in the accessibility settings to turn it on fails 1.4.11. This is a somewhat technical argument and there is no "there is a mechnism" wording in 1.4.11 but I think it can be assumed to be implied?

[JJdeGroot]

In today's meeting, @detlevhfischer mentioned: "ACTION: Add agenda item for contrast exception for OS-driven keyboard focus". We will consider this in the next meeting that will cover 1.4.11