Success Criterion 1.4.3 - Contrast (Minimum) - Level AA

[JJdeGroot]

MATF meeting on July 17, 2024

[Source](https://www.w3.org/2024/07/17-matf-minutes.html#t04) JJ: Raises the point about large text measurements +1 to Illai Thank you. I missed it +1 to Illai comment on sizing - I like what the Evinced MCAG guidelines did in reducing to a standard measurement It would be nice if we knew what minimum text size is... Regarding the large text - with screen glare and viewport size i think there's an argument to require all text to meet 4.5:1 contrast. Also lot of time testers won't have access to native code in my experience when testing and as a result there's an inability to accurately determine the font size of text in native applications. JJ digs to the notes - perhaps we can make this more discoverable? JJ points out SP for android text +1 to mick and quintinb re minimum text size For what it's worth, I have tried to formulate a way of assessing whether text falls under "large text" based on screenshots and measurements of font height (it's in German so you would have to get this translated by your browser) https://bitvtest.de/pruefschritt/bitv-20-app/bitv-20-app-11-1-4-3-kontrast-minimum#_3_3_berechnung_der_schriftgr%C3%B6%C3%9Fe_auf_screenshots ) There are places where a reference to some kind of tool would be useful (e.g. input SP size) Detlev can you summarize in a sentence? +1 to Mick +1 to what JJ is saying about real color vs. coded color and size of text You take a screenshot, load into something like Photoshop take into account the physical to CSS pixel ratio, measure text height... JJ: 2 issues - 1. When no source access - testing is difficult 2. Determine the font size (also source problem) @Jamie does that help? APCA is not current WCAG guidance... Aashutosh: Since WCAG is rated for desktops and phones live in the wild, should we not reconsider contrast. There are also different mechanisms for measuring contrast, should we use things like APCA (I might have missed this) JJ: APCA is not relevant for 2.2 at the moment, but it has utility quintinb the question was two parts. 1. should the contrast ratio be stricter for the apps, since the mobiles can be taken outdoors in brighter sunlight and under direct glare. 2nd. should we use APCA over traditional contrast Jamie: Should we have SC specifically for conditions where source access is not possible ACTION: How to deal with source code access vs no-source code access when testing Thanks Aashutosh - trying to keep up and actually listen! I had a bad suggestion lol JJ: Can we expect testers to have access to tools - there are many hurdles to that (e.g. platform / cost) I agree with Aashutosh to be honest - impact could be fairly big Regarding requirements around access to source code or not - I think it's so important the mapping we provide for native mobile are testable given how they are pointed to by legislation. And i think a lot of testers unfortunately just don't have access to code and would be my recommendation on how we measure what is testable. +1 to mick +1 Mick - text should be a "reasonable" size - but what that means I don't know +1 to emphasize what is testable

WCAG2ICT guidance: https://w3c.github.io/wcag2ict/#contrast-minimum

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

[illai]

This success criterion is allegedly clear and straightforward. However, it poses a challenge when referring to the measurement units. Unlike the web on mobile, there is one platform that uses PT (points) as measurement units for text (iOS), while the other platform (Android) uses SP (Scalable Pixel) for this. Sticking to PT (points) as measurement units (which makes sense) will probably require, in the context of native mobile apps, at least a clarification and an indication of how to convert units correctly to the relevant measurement units for the platform (which I think is also missing in WCAG today)

[qbalsdon]

There might be a need to consider research on colour contrasts for smaller screens, but until that is done I am happy with this criterion remaining as is for mobile.

[qbalsdon]

@illai I'm not sure if I understand - are there units in colour contrast, or is this comment for Touch Target Sizes?

[qbalsdon]

Can we please add a condition onto this one to reference "Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;" (sometimes called "disabled" or "not enabled") - in 1.4.11 Non text contrast

It's understandable and predictable that creators will prevent interaction by this mechanism, and we should add some info:

1. It's fine as long as state is conveyed
2. inactive components do not need to meet colour contrast rules and best practice is to inform users why the component is inactive, but not required

[illai]

@qbalsdon The Color contrast SC has size dependencies. Contrast of at least 4.5:1 for texts blow 18 points, Contrast of at leas 3:1 for texts above 18 points. The measurement units referred on this SC are points. While it make sense to measure typography with points it also the iOS text units, while Android uses other unuts. I think that it would be important to clarify that point.

[qbalsdon]

@illai Thank you - I missed that!

[Keanem6]

Should we be include requirements for Dark mode as well?

[AlainVagner]

@illai just one question about this. As I understood in MCAG, the threshold is at 18 points for normal text and 14 points for bold (same on Apple and Android guidelines). The points you mention here are I suppose sp for Android and pt for iOS. Is that correct? The definition of points is quite different on the web and on native mobile platforms (1/72 of an inch on the Web), can we reliably consider that they are equivalent?

I agree with you that we should clarify this point. We can evaluate a font size with @detlevhfischer 's method based on thresholds in css pixels, but we need also to have clear thresholds for developers in the native units.