AccessLumens

WCAG 1.4.11

Non-text Contrast

SeriousLevel AAWCAG 2.1

4.9%

of the 609 sites we scanned fail this

Ranging from 3.3% of Indian financial services to 13.5% of US healthcare providers. Pooled across five targeted cohorts, so treat it as a convenience sample rather than a rate for the web.

What it means and how to fix it

What 1.4.11 covers

  • Partly detected: Control boundaries and icons below 3:1 against their backgroundWe check the boundaries of interactive controls. Coverage is narrower than the criterion, which also spans graphics needed to understand content.
  • No engine can detect this: Meaningful graphics, chart elements and infographic parts below 3:1Deciding which parts of a graphic are needed to understand it is a judgement about the content.
  • Partly detected: Contrast of the focus indicator itselfWe detect an indicator that was removed entirely. One that is present but too faint is measured only in part.

Of that, one failure is detectable automatically, and these are what the rates on this page measure. Each needs its own fix. The percentage is the share of all 609 scanned sites affected. These do not sum to the 4.9% above: a site can fail more than one of them, and most that fail any fail several.

  • Form fields have no visible boundary4.9%

    Form fields with no border, fill, or shadow that contrasts with the background are hard for users with low vision to locate — they can't tell where to type or that a control is even there.

What it looks like in code

CSS
Fails
.input {
  border: 1px solid #d9d9d9;   /* 1.4:1 on white, fails */
}
Passes
.input {
  border: 1px solid #767676;   /* 4.6:1 on white, passes */
}

Controls and their boundaries need 3:1. The failing value is the hairline border that makes a form look calm and makes the field invisible to anyone with reduced contrast sensitivity.

Shown for Form fields have no visible boundary. Both halves are written rather than harvested: this failure lives in CSS rather than in the markup, so there is no page element to show.

For what the criterion formally requires, read the W3C Understanding document.

How often it fails

US healthcare providers28/208
13.5%
Indian financial services2/61
3.3%

Share of scanned sites in each cohort. These are five targeted studies, not a random sample of the web, so read the contrast between cohorts rather than any one figure as a web-wide rate.

Who fails it mostOne cut by state

By state

NY2/8
25%
FL3/15
20%
MO1/8
12.5%
OH1/8
12.5%
LA1/9
11.1%
CA2/25
8%
TX0/13
0%
KS0/10
0%

Groups smaller than 8 sites are not shown: a rate over a handful of sites moves by tens of points on a single result.

What this does not measureLimits of these figures, and where the corpus came from
  • These are five targeted cohorts, not a random sample of the web. Per-cohort rates are the figure to quote; the pooled rate is a convenience sample.
  • Denominators count sites that produced a result. Sites that were blocked or errored are excluded rather than counted as passing.
  • Occurrence counts are floors: the engine records at most 25 occurrences of a rule per page.
  • The EU and Indian cohorts retained only the primary success criterion per finding, so a rule mapping to several criteria contributes to one of them in those two cohorts and to all of them in the other three.
Cohorts in the corpus, with sites scanned and attempted
CohortScannedAttempted
Shopify DTC stores7575
US local government158221
US healthcare providers208218
EU e-commerce107170
Indian financial services6172

Corpus generated 2026-09-18.

Check your own site

A free scan reports WCAG 1.4.11 alongside everything else, with the exact elements that fail.

Run a free scan

All accessibility rules and WCAG criteria