1.4.3 Contrast (Minimum)
- Level AA
- Perceivable
- Since WCAG 2.0
Summary
Low contrast text is the single most frequently reported accessibility failure on the web, and it is trivially measurable. This criterion requires ordinary body text to have a contrast ratio of at least 4.5:1 against its background, relaxing to 3:1 for large text. "Large" has a precise definition: at least 18 point (roughly 24 CSS pixels) at regular weight, or at least 14 point bold (roughly 18.66 CSS pixels). Anything smaller than that is body text and must hit 4.5:1, however prominent it looks.
The people this protects are not only those with clinically low vision or colour vision deficiencies. Contrast degrades for everyone with age, and situationally for anyone reading a phone in sunlight, on a dim screen, or through glare. The criterion has been at Level AA since WCAG 2.0, and three carve-outs limit its scope: incidental text (inactive controls, pure decoration, text hidden from everyone, or text inside a photo with significant other visual content), and text that forms part of a logo or brand name.
Official wording
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no contrast requirement.
EN 301 549 mapping
- Web pages
- Clause 9.1.4.3
- Software and native apps
- Clause 11.1.4.3
Clauses 9.1.4.3 (web) and 11.1.4.3 (software) apply this criterion unchanged, so the same contrast thresholds bind websites and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Measure the rendered colours, not the design tokens. What the specification grades is the colour the user actually sees, so opacity, colour blending, filters, and dark mode overrides all matter: a token defined as #595959 rendered at 60 percent opacity over white is a much lighter grey by the time it reaches the screen. Inspect the element in browser developer tools and read the computed foreground and background, or sample the pixels directly.
Text over gradients, images, or translucent panels has no single background colour. Sample the worst point: the spot where the text and background come closest in luminance. If the lightest part of a hero image sits behind white text, that is where you measure, and the whole run of text passes or fails on that worst case. AUDITSU's free colour contrast checker computes the ratio and grades it against both thresholds, and its screen eyedropper lets you sample any pixel on screen, which is exactly what gradient and image backgrounds need.
Two states cause most disputes. Placeholder text in form fields is real text conveying real information, so it must meet the ratio; the default light grey placeholder in many component libraries does not. Disabled controls, by contrast, are exempt: text on an inactive user interface component falls under the incidental exception. The judgement call is whether the control is genuinely inactive, not merely styled to look faint.
iOS
The thresholds are identical for native apps: EN 301 549 applies this criterion unchanged to software, so an iOS screen is graded exactly like a web page. The practical difference is how you sample. Take a screenshot from the simulator or device and use an eyedropper (the one in the contrast checker linked above works on anything visible on your screen) to read the rendered foreground and background values, then compute the ratio. Grade the app as shipped, not the values in the design file, because vibrancy effects, materials, and blurs shift colours at render time.
Dynamic Type deserves attention. When a user scales text up, a label can cross the large-text boundary, but the thresholds are keyed to the point size actually rendered on the screen under test, so record the size alongside the sample. A 17 pt regular label is body text and needs 4.5:1 regardless of how large it might become at bigger settings.
Dark mode is a separate test surface. If the app supports both appearances, both must pass, and the failures rarely mirror each other: a mid grey that passes on white commonly fails on a dark background. Audit each appearance as its own set of screens.
Android
The same sampling approach applies: screenshot the running app from the emulator or a device, eyedrop the rendered text and background, and compute the ratio. As on iOS, elevation overlays, ripple states, and translucent surfaces mean rendered colours can differ from theme values, so measure the pixels.
Theme variants multiply the work. Light and dark themes must each pass, and on modern Android versions dynamic colour derives the palette from the user's wallpaper, so text roles that looked safe in the default theme can land on lower-contrast tonal combinations. Test the theme variants the app actually ships, including at least one dynamic colour palette if the app opts in.
Platform accessibility scanning built into modern Android tooling flags text it estimates to be below the contrast thresholds. Treat those flags as leads, not verdicts: the estimation can misjudge text over images and translucent surfaces, so always confirm the measured ratio before recording a result.
Pass and fail examples
Passes:
- Body text in
#767676on a white#ffffffbackground: 4.54:1, just clearing the 4.5:1 floor. This is close to the lightest grey that passes on white. - A 24 px regular heading in
#949494on white: 3.03:1, which passes only because the text qualifies as large; the same colour in body copy fails. - White text on the brand blue
#3b82f6at 28 px bold: 3.68:1 passes the large-text threshold. The same white-on-blue combination in a 14 px caption fails. - The company name rendered in a low-contrast logotype: exempt as a logo, whatever the ratio.
- Faint text on a greyed-out, genuinely disabled submit button: exempt as part of an inactive user interface component.
- A street sign captured incidentally in a photograph of a city scene: text that is part of a picture containing significant other visual content has no requirement.
Fails:
- Body text in
#999999on white: 2.85:1, well short of 4.5:1 despite being a common "subtle" grey in interface design. - Placeholder text in
#aaaaaainside an active input on a white field: about 2.3:1, and placeholders are not exempt. - White body text over the pale sky region of a hero photograph: measured at the lightest point behind the letters, the ratio collapses even if the darker areas would pass.
- A 20 px regular price label graded against 3:1 on the theory that it "looks big": 20 px regular is below the large-text boundary, so 4.5:1 applies and the label fails.
Commonly confused with
- Non-text Contrast, SC 1.4.11. Icons, input borders, focus indicators, and other meaningful graphics are graded at 3:1 under 1.4.11 Non-text Contrast, not 4.5:1 here. Citing a 4.5:1 expectation against an icon is the classic mixed-up finding; this criterion is text and images of text only.
- Grading a logo. Logotypes are explicitly exempt. A finding against the contrast of a brand wordmark is a false fail, though the same colours reused in navigation or headings are fully in scope.
- Points versus pixels. The large-text boundary is defined in points, and 1 pt is 1.333 CSS px, so 18 pt is 24 px and 14 pt bold is 18.66 px. Reading "18" as 18 px (which is only 13.5 pt) and applying the 3:1 threshold to it is the most common source of wrong results in contrast audits.
- Contrast (Enhanced), SC 1.4.6. The Level AAA sibling demands 7:1 for body text and 4.5:1 for large text. If a report cites 7:1 against a Level AA audit, the AAA criterion has been applied by mistake.
How AUDITSU tests this
AUDITSU's audit walkthrough includes text contrast in its visual checks for every screen you review. The walkthrough prompts you to identify suspect text (light greys, text over images, placeholders, secondary labels), sample the rendered foreground and background at the worst point, and grade the measured ratio against the correct threshold for the text's size and weight. Each check records a pass, fail, or not applicable result per screen with the evidence attached, so findings land in your report tied to the exact screen and text.
Because EN 301 549 applies this criterion unchanged to both web content and software, the same 4.5:1 and 3:1 thresholds bind websites and native app UIs, and AUDITSU grades them identically across platforms in European Accessibility Act audits.
For the full guided workflow, see the audit platform.