Barrierefreiheit | Blog | Tutorials and know-how

What does a WCAG contrast checker test for in text elements?

Eckhard Schneider
Published by Decareto
·
8min read
·
September 1, 2026
Table of Contents

A WCAG contrast checker tests text elements to determine whether the contrast ratio between the text colour and the background colour meets the minimum values defined in the Web Content Accessibility Guidelines. Specifically, the tool calculates the difference in brightness between the two colours and compares it with the threshold values for Conformity Levels AA and AAA.

The following sections answer the most important questions regarding contrast testing, technical calculations and the targeted rectification of errors.

What contrast ratios are considered WCAG-compliant for text?

For normal text, a contrast ratio of at least 4.5:1 is considered WCAG-compliant at Conformity Level AA, and at least 7:1 at Level AAA.

For large text – that is, text in 18-point or larger regular font, or 14-point or larger bold font – lower thresholds apply: 3:1 at level AA and 4.5:1 at level AAA. These values always refer to the ratio between the relative luminance of the text colour and the relative luminance of the background.

The distinction between normal and large text is crucial because larger type remains legible even at lower contrast levels. People with visual impairments, including many older users, benefit particularly from sufficient contrast, as they perceive colour differences less clearly than people without such impairments.

The WCAG do not specify any contrast requirements for decorative text elements, logos and inactive controls. The key factor, therefore, is whether a text element is relevant to the content and thus falls within the scope of the test at all. The accessibility test automatically takes precisely these distinctions into account.

How does a contrast checker technically calculate the contrast ratio?

A WCAG contrast checker calculates the contrast ratio by first determining the relative luminance of both colours involved using the WCAG formula, and then calculating the ratio of the brighter luminance to the darker luminance. The result is a number between 1:1 (no contrast, identical colours) and 21:1 (maximum contrast, black on white).

The calculation of relative luminance follows a standardised procedure: each RGB colour value is first converted into a linear value to correct for the non-linear perception of the human eye. This step, known as gamma correction, is necessary because screens do not display colours linearly. The corrected red, green and blue values are then multiplied by specified weighting factors and added together, as the human eye perceives green as significantly brighter than blue.

The final contrast ratio is calculated using the formula: (L1 + 0.05) /

(L2 + 0.05), where L1 is the higher luminance and L2 the lower. The addition of 0.05 prevents division by zero in the case of absolutely black areas. Automated tools such as a WCAG Contrast Checker carry out this calculation for every text element on the page, without you having to apply the formula yourself.

Which text elements does a WCAG Contrast Checker check – and which does it not?

A WCAG Contrast Checker checks all text elements on a web page that are relevant to the content, including body text, headings, links, buttons, form fields, navigation elements and tooltips. Decorative text elements with no informational content, logos, word marks and text in inactive controls are not checked, as the WCAG expressly does not specify any contrast requirements for these categories.

Particular attention should be paid to the following elements, which are often overlooked in practice:

  • Placeholder text in input fields: These are considered content-relevant and must meet the contrast requirements, even though they are often displayed in a visually subdued manner.
  • Text on images: If text is superimposed on an image or a colour gradient, the contrast must be checked against the actual background area, not against an average colour.
  • Focus and hover states: If the text colour changes upon interaction, the contrast in the altered state must also meet the requirements.
  • Disabled controls: These are exempt from the testing requirement as long as they are clearly recognisable as inactive.

Automated tools can only check text on complex backgrounds, such as colour gradients or background images, with limited reliability. In such cases, a manual follow-up check is recommended to ensure that no contrast issues are overlooked.

Who benefits from this?

According to Deque University:

  • Almost three times as many people have visual impairments as those who are completely blind
  • 1 in 12 people have colour vision deficiency (~8% of men, ~0.4% of women)
  • People with cataracts, age-related macular degeneration or reduced contrast sensitivity

What is the difference between WCAG AA and AAA regarding text contrast?

The difference between WCAG AA and AAA in terms of text contrast lies in the level of requirement: AA is the legally relevant minimum standard for most websites and requires a ratio of 4.5:1 for normal text and 3:1 for large text. AAA is the highest level of conformance and requires a ratio of 7:1 for normal text and 4.5:1 for large text. It is intended for websites with particularly high accessibility requirements.

In Germany, the AA level of compliance is the relevant benchmark for public bodies and many private-sector websites, for example in the context of the Act on Strengthening Accessibility (BFSG). Full AAA compliance is neither legally required for most websites nor practically achievable in all areas, as individual AAA criteria sometimes conflict with other design requirements.

For your organisation, this means: first ensure that all relevant text elements meet the AA level. AAA criteria can be pursued as a voluntary improvement, particularly where your target audience has an increased need for accessibility, such as on healthcare or government portals. When running a WCAG test, you can filter the report by conformance level to view AA and AAA findings separately.

Why does a contrast checker flag text that appears to be legible?

A contrast checker flags text that is subjectively legible because the WCAG thresholds are not based on subjective legibility, but on measurable luminance values designed to ensure sufficient contrast for people with visual impairments. What appears easily readable to a person with normal vision may already present a significant barrier to people with colour blindness, cataracts or age-related reduced contrast sensitivity.

In addition, there are technical factors that influence perceived contrast:

  • Font size and weight: Small or thin fonts are more difficult to read than large, bold fonts, even with the same contrast ratio. The Contrast Checker takes this into account by applying different thresholds for normal and large text.
  • Screen calibration: On a poorly calibrated or very bright monitor, text may appear to have sufficient contrast even though the measured ratio falls below the threshold.
  • Ambient light: In bright sunlight or when there are reflections on the display, the perceived contrast decreases significantly, even if the screen itself displays sufficient contrast.
  • Colour combinations: Certain colour pairs, such as medium grey on white or pastel shades on a light background, appear more legible to the eye than they are when measured.

The aim of the WCAG contrast requirements is to include a broad group of users, not just people with average vision under optimal conditions. That is why objective measurement using an accessibility testing tool is more reliable than subjective perception.

How can contrast issues in text elements be specifically resolved?

The most direct way to resolve contrast issues in text elements is to adjust the text colour, the background colour, or both, so that the contrast ratio meets the WCAG threshold. You should proceed systematically to maintain design consistency and avoid introducing new problems.

The following steps have proven effective in practice:

Prioritise errors: Start with text elements that are central to the user experience, such as buttons, form fields and navigation elements. Errors in these areas block basic functions and are therefore more serious than contrast issues in footers or help texts.

  • Adjust colour values systematically: Use an interactive Contrast Checker that shows you in real time how colour changes affect the contrast ratio. Often, slightly darkening the text colour or lightening the background is sufficient.
  • Update the design system: If your website is based on a central colour system or a CSS framework, adjust the colour variables in one central location. This ensures the corrections are automatically applied to all affected elements.
  • Consider font size as an alternative: In some cases, increasing the font size to over 18-point regular or 14-point bold can lower the applicable threshold from 4.5:1 to 3:1, thereby rectifying the issue without having to change the colours.
  • Check the result again: After making the correction, you should scan the affected pages again to ensure that the changes have the desired effect and that no new problems have arisen.

It is important not to consider contrast corrections in isolation. A change to the primary colour can affect many elements that were not initially the focus of attention. Ongoing monitoring using an accessibility testing tool helps to identify newly introduced barriers at an early stage.

How decareto supports you with contrast testing

At decareto, we have developed our accessibility software so that contrast issues and other accessibility errors can be identified quickly, systematically and transparently. We rely on the tried-and-tested open-source library axe-core, which checks the HTML code of every single page for compliance with WCAG guidelines. What this means for your work in practical terms:

  • Automated WCAG contrast check: Our tool checks contrast ratios on all subpages of your website, including password-protected areas, and displays the locations of any issues with HTML code and a screenshot.
  • Prioritisation by severity: Contrast errors are classified by criticality so that you know which problems should be resolved first.
  • Filtering by WCAG conformance level: You can view AA and AAA findings separately and focus specifically on the standard relevant to your legal requirements.
  • Specific recommendations for action: For every issue found, we provide clear guidance on how to resolve it, in a way that is understandable to both developers and consultants.
  • Continuous monitoring: Hundreds of websites can be monitored continuously. You’ll receive automatic notifications of any changes, ensuring that new barriers do not go unnoticed.
  • White-label reports: External service providers can pass on reports to clients under their own logo.

Please note: A good result in the automated scan does not mean that there are no further barriers. Automated tests typically cover around 30 to 50 per cent of all possible accessibility issues. For a comprehensive assessment, we recommend combining automated scans with manual checks. Start your first free test now and receive a structured overview of your website’s contrast situation in just a few minutes.

Related Articles

Related Articles

Social Share:

Explore more related blogs

1min read
·
November 11, 2026
In diesem Leitfaden beschreiben wir die zehn wichtigsten Punkte für die technische Umsetzung und bieten ...
1min read
·
November 10, 2026
How can data protection professionals audit websites with less effort? Find out which GDPR checks ...
1min read
·
November 9, 2026
Why a scan alone isn’t enough, and how to identify, assess and prioritise barriers on ...