WCAG 1.4.11: Non-text Contrast

What This Rule Means

WCAG 1.4.11 Non-text Contrast is a Level AA criterion introduced in WCAG 2.1 and carried forward into WCAG 2.2. It mandates a minimum contrast ratio of 3:1 between the visual presentation of the following two categories of content and their adjacent color(s):

• User Interface (UI) Components: The visual boundaries or indicators that identify interactive controls such as text inputs, checkboxes, radio buttons, toggle switches, dropdown menus, and buttons. This includes both the component itself and any visual state changes (e.g., hover, focus, selected, error).
• Graphical Objects: Parts of icons, charts, diagrams, and other meaningful images that are required to understand the content. Each part of the graphic that conveys information must meet the 3:1 threshold against its surrounding color.

The contrast ratio is measured between the foreground element and the color immediately adjacent to it — typically its background color, border color, or a neighboring segment of a chart. The calculation uses the same relative luminance formula defined in WCAG 1.4.3, but the threshold is 3:1 rather than 4.5:1 because non-text elements can afford slightly lower contrast while remaining discernible.

A pass means every visual indicator that identifies a UI component or communicates information in a graphic achieves at least a 3:1 ratio. A fail occurs when a border, icon stroke, chart segment, or state indicator falls below this ratio and the component or graphic cannot be identified or understood without that visual information.

The WCAG specification defines several important exceptions:

• Inactive components: UI components that are disabled and not available for interaction are exempt. A greyed-out button that cannot be clicked does not need to meet the contrast requirement.
• Appearance controlled by the user agent: Components whose visual presentation is entirely controlled by the browser's default styling (not overridden by author CSS) are exempt, because the responsibility lies with the browser vendor.
• Essential or decorative graphics: Graphical objects where the particular presentation is essential to the information being conveyed (e.g., national flags representing countries) or that are purely decorative are exempt. Logos are also generally exempt under this clause.
• Text: Text and images of text are already covered by 1.4.3 and 1.4.6 and do not fall under 1.4.11.

Focus indicators deserve special attention in WCAG 2.2. Criterion 2.4.11 (Focus Appearance) adds stricter requirements for focus visibility, but 1.4.11 still applies to the contrast of any custom focus ring against its background. A custom outline or box-shadow used as a focus indicator must achieve 3:1 against the adjacent color to satisfy this criterion independently.

Why It Matters

Approximately 2.2 billion people worldwide have some form of vision impairment, according to the World Health Organization. A significant proportion of these individuals — including the estimated 253 million people living with moderate to severe vision loss — rely on sufficient contrast to perceive and interact with digital interfaces without necessarily using a screen reader. Low vision users who browse with magnification software, high-contrast modes, or simply in challenging lighting conditions are among those most directly affected by 1.4.11 failures.

Consider a practical scenario: a user with glaucoma is filling out an insurance claim form on a hospital's website. The form fields use a light grey border (#cccccc) on a white background (#ffffff), which yields a contrast ratio of only 1.6:1 — far below the required 3:1. The user cannot see where the input fields begin and end, so they cannot reliably click into them or understand the form's structure. They abandon the form entirely, which has both a personal cost and a legal liability for the institution.

Beyond vision impairment, cognitive disabilities can also make low-contrast UI components harder to interpret. Users with attention disorders or processing difficulties rely on strong visual differentiation between interactive and non-interactive elements to understand page structure quickly. Similarly, users with tremors or motor impairments who use large pointer targets need to clearly see the boundaries of controls to aim accurately.

From a business perspective, meeting 1.4.11 improves usability for all users in suboptimal conditions — bright sunlight on a mobile screen, low-quality monitors, or older displays with poor color accuracy. It reduces support costs, broadens audience reach, and strengthens SEO indirectly by lowering bounce rates tied to poor usability. For organizations subject to legal accessibility mandates, failing this criterion at Level AA poses direct compliance risk.

Related Axe-core Rules

• color-contrast (partial coverage): The axe-core color-contrast rule primarily targets text contrast under WCAG 1.4.3, but it also performs partial checks for non-text elements in certain contexts. Axe flags UI components like buttons and form controls when it can programmatically determine that the visual boundary or background of the component fails the 3:1 ratio. However, the rule's coverage is explicitly marked as partial for 1.4.11 because many contrast failures for non-text elements are invisible to automated analysis. For example, the contrast of an SVG icon's stroke against its background, or the border of a custom-styled checkbox implemented with CSS pseudo-elements, cannot be reliably extracted from the DOM without rendering context. The computed style of a CSS border may be present in the accessibility tree but the adjacent background — especially when it is a gradient, image, or overlapping element — is not always computable programmatically. This is why axe reports 1.4.11 violations under the color-contrast rule with a needs review designation in many cases, meaning the tool has detected a potential issue but a human must confirm it by visually inspecting the element and using a color contrast analyzer tool to sample the actual rendered pixels.

Because automated tools can only detect a fraction of non-text contrast failures, manual testing is essential. Tools like the Colour Contrast Analyser (TPGi), browser DevTools color pickers, or the Accessible Colors tool must be used to sample foreground and background colors directly from the rendered interface. Automated scans should be treated as a first pass, not a comprehensive audit.

How to Test

1. Run an automated scan with axe DevTools or Lighthouse: Install the axe DevTools browser extension and run a full-page scan. In the results panel, filter for issues tagged with WCAG 1.4.11 or review any color-contrast violations. Note any items flagged as Needs Review under the non-text contrast category — these require manual follow-up. In Lighthouse (Chrome DevTools > Lighthouse tab), run an Accessibility audit and review the contrast-related findings, keeping in mind Lighthouse's coverage is also partial for non-text elements.
2. Manual inspection with a color contrast analyzer: Download and open the TPGi Colour Contrast Analyser desktop application. Use its eyedropper tool to sample the foreground color of each UI component boundary (e.g., the border of a text input, the stroke of an icon, the fill of a chart bar) and then sample the adjacent background color. The tool will display the computed contrast ratio. Any ratio below 3:1 is a failure. Work through all interactive form controls, icon-only buttons, focus indicators, and data visualizations systematically.
3. Keyboard navigation and focus indicator test: Tab through the entire page using only the keyboard. For each interactive element that receives focus, verify that the focus indicator (ring, outline, or background change) is visible. Use the contrast analyzer to confirm the focus indicator color achieves 3:1 against the element's background. Test in NVDA + Firefox and JAWS + Chrome to confirm the element receives focus in the expected order and that the visual indicator is not suppressed by CSS outline: none without an equivalent replacement.
4. Test in high-contrast and forced-color modes: In Windows, activate High Contrast mode (Settings > Ease of Access > High Contrast) and reload the page. In Chromium-based browsers, open DevTools, go to Rendering, and enable the Emulate CSS media feature forced-colors: active option. Verify that UI component boundaries remain visible. While forced-color mode compliance is not strictly required by 1.4.11, testing in this mode reveals elements that rely solely on low-contrast color cues.
5. Verify graphical objects in context: For each chart, icon, diagram, or informational image, identify every segment or path that conveys meaning. Use the eyedropper tool to sample adjacent colors within the graphic itself (e.g., two neighboring pie chart segments) and against the surrounding page background. Each distinct part that communicates information must individually achieve 3:1.
6. Check all component states: Interactive elements have multiple states — default, hover, focus, active, selected, checked, error, and success. Test each state separately. A button border that passes in its default state may fail in its hover state if the color changes to a low-contrast variant.

How to Fix

Form Input Border — Incorrect

<!-- Fails: light grey border (#cccccc) on white (#ffffff) = 1.6:1 ratio -->
<style>
  .form-input {
    border: 1px solid #cccccc;
    background-color: #ffffff;
    padding: 8px 12px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Form Input Border — Correct

<!-- Passes: darker border (#767676) on white (#ffffff) = 4.54:1 ratio, exceeds 3:1 -->
<style>
  .form-input {
    border: 1px solid #767676; /* Darkened to achieve sufficient contrast */
    background-color: #ffffff;
    padding: 8px 12px;
  }
  .form-input:focus {
    outline: 3px solid #005fcc; /* Focus ring at 5.9:1 against white */
    outline-offset: 2px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Icon-only Button — Incorrect

<!-- Fails: light grey icon (#aaaaaa) on white (#ffffff) = 2.32:1 ratio -->
<style>
  .icon-btn { background: none; border: none; color: #aaaaaa; }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Icon-only Button — Correct

<!-- Passes: dark icon (#595959) on white (#ffffff) = 7:1 ratio, well above 3:1 -->
<style>
  .icon-btn { background: none; border: none; color: #595959; cursor: pointer; }
  .icon-btn:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 4px;
  }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <!-- Darker stroke ensures the icon shape is perceivable -->
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Custom Checkbox — Incorrect

<!-- Fails: custom checkbox uses a light border (#d0d0d0) on white background -->
<style>
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #d0d0d0; /* 1.3:1 ratio against white — fails */
    border-radius: 3px;
    display: inline-block;
  }
</style>
<label>
  <input type='checkbox' style='position:absolute;opacity:0;width:0;height:0' />
  <span class='custom-checkbox-box'></span>
  I agree to the terms
</label>

Custom Checkbox — Correct

<!-- Passes: border (#5a5a5a) on white = 7.2:1. Checked state tick also uses sufficient contrast -->
<style>
  .custom-checkbox-input {
    position: absolute; opacity: 0; width: 0; height: 0;
  }
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #5a5a5a; /* Sufficient contrast against white background */
    border-radius: 3px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background-color: #ffffff;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box {
    background-color: #005fcc; /* Blue fill on checked */
    border-color: #005fcc;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box::after {
    content: '';
    display: block;
    width: 10px; height: 6px;
    border-left: 2px solid #ffffff; /* White tick on blue = 5.9:1 */
    border-bottom: 2px solid #ffffff;
    transform: rotate(-45deg) translateY(-2px);
  }
  .custom-checkbox-input:focus-visible + .custom-checkbox-box {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>
<label class='custom-label'>
  <input type='checkbox' class='custom-checkbox-input' />
  <span class='custom-checkbox-box' aria-hidden='true'></span>
  I agree to the terms
</label>

Data Chart — Incorrect

<!-- Fails: two adjacent pie chart segments use similar light hues with <3:1 contrast -->
<svg viewBox='0 0 200 200' aria-label='Market share chart' role='img'>
  <!-- Segment A: #f5c6cb (light pink) adjacent to Segment B: #ffeeba (light yellow) -->
  <!-- Contrast ratio between these two colors is approximately 1.1:1 — fails -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#f5c6cb' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#ffeeba' />
</svg>

Data Chart — Correct

<!-- Passes: use high-contrast segment fills OR add a visible border between segments -->
<svg viewBox='0 0 200 200' aria-label='Market share chart: Segment A 50%, Segment B 25%' role='img'>
  <!-- Option 1: Use a dark stroke between segments to separate them at 3:1 against both fills -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#d63384' stroke='#ffffff' stroke-width='2' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#0d6efd' stroke='#ffffff' stroke-width='2' />
  <!-- The white (#ffffff) stroke separates the two segments; each fill also has 3:1 against white bg -->
</svg>

Common Mistakes

• Using a single-pixel border that passes 3:1 but becomes invisible at low DPI: Even a compliant color can become imperceptible if the border is only 1px wide on a low-resolution screen. Use border: 2px solid or a visible box-shadow alongside a compliant color to ensure the boundary is physically perceivable.
• Assuming the background is always white: When a form field or icon appears inside a card or sidebar with a light grey background (#f5f5f5), the contrast must be measured against that grey, not against white. A border that passes on white may fail on a tinted background.
• Removing the default focus outline with outline: none and not providing an equivalent: This is one of the most common 1.4.11 failures. Setting :focus { outline: none; } globally destroys focus visibility for keyboard users. Always replace it with a custom focus style that achieves at least 3:1 contrast against its background.
• Treating disabled state as an excuse to skip all contrast checks: Disabled components are exempt, but developers sometimes mark elements as visually disabled via low-contrast styling without actually adding the disabled attribute or aria-disabled='true'. An element that looks disabled but is still interactive must still pass 1.4.11.
• Relying solely on color to differentiate chart segments without a separating stroke: Two adjacent chart segments where the only differentiator is hue (e.g., light blue vs. light green) may fail if their contrast ratio is below 3:1. Adding a 2px white or dark separator stroke between segments is a reliable fix.
• Applying contrast fixes only to the default state and forgetting hover, focus, error, and success states: Each interactive state has its own visual presentation. A button border that passes in the default state may shift to a low-contrast color on hover. All states must be tested independently.
• Embedding icons as background images and relying on CSS color for contrast: SVG icons inlined in HTML respond to color and currentColor, but icons used as CSS background-image cannot be recolored via CSS. If the icon image file itself has insufficient contrast, no CSS fix can resolve the issue without replacing the asset.
• Forgetting that placeholder text in inputs is not covered by 1.4.11 but is still regulated: Placeholder text falls under 1.4.3 (text contrast at 4.5:1), not 1.4.11. Developers sometimes apply the 3:1 threshold to placeholder text by mistake, creating a separate, unnoticed 1.4.3 failure.
• Using CSS transitions that animate through a non-compliant intermediate color: An element might animate from a passing color through a failing intermediate color to another passing color. Even if the start and end states pass, the visual component is technically non-compliant during the transition. Use prefers-reduced-motion media queries thoughtfully and avoid routing transitions through low-contrast states.
• Ignoring progress bars, range inputs, and toggle switches: These custom UI components are frequently styled without consideration for 1.4.11. The filled portion of a progress bar must have 3:1 contrast against its track; a toggle's knob must contrast against the toggle's background; a range input's thumb must contrast against the track.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular No. 2025/10, published in Official Gazette No. 32933 on June 21, 2025, establishes mandatory web and mobile accessibility requirements for a broad range of public and private entities operating in Turkey. The Circular adopts WCAG 2.2 as its normative technical standard, and Level AA conformance is the required threshold for compliance.

WCAG 1.4.11 Non-text Contrast, as a Level AA criterion, is therefore directly enforceable under the Circular. Organizations subject to the regulation must ensure that all UI component boundaries, interactive control states, and meaningful graphical objects on their digital properties meet the 3:1 non-text contrast requirement.

The entities covered by Presidential Circular 2025/10 include public institutions and agencies at all levels of government, e-commerce platforms, banks and financial institutions, hospitals and private health providers, telecommunications operators with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE). For these organizations, a failure to implement 1.4.11 is not merely a best-practice shortcoming but a regulatory non-conformity.

The Accessibility Logo (Erişilebilirlik Logosu), issued by the Ministry of Family and Social Services, serves as a publicly visible certification mark for compliant digital services. To obtain and display this logo, an organization must demonstrate full Level AA conformance across all applicable WCAG 2.2 criteria, including 1.4.11. Because many Turkish e-government portals, banking interfaces, and healthcare forms make extensive use of custom-styled form controls and data visualizations, non-text contrast is a criterion that auditors are particularly likely to evaluate during the certification process.

Organizations using the Accsible overlay widget should be aware that overlay technology can assist with remediating certain runtime contrast adjustments — such as allowing users to activate a high-contrast theme — but persistent structural failures, such as a form input rendered with a 1.6:1 border contrast, must be corrected at the source code level to achieve genuine conformance and qualify for the Erişilebilirlik Logosu. Combining source-level fixes with an accessibility widget's user-facing enhancement features represents the most defensible compliance posture under Turkish law.