Implementing WCAG contrast and font sizes

WCAG contrast: where the interface stops being readable

Low interface contrast is almost never visible in a mockup — it shows up on real screens and under real lighting.

Typical places are always the same: gray labels under input fields, thin-weight text at small sizes, semi-transparent overlays on top of photos, disabled and hover states of buttons, hints, and error messages in forms.

Formally, WCAG contrast is measured by the contrast ratio of text and background: normal text requires 4.5:1, large text — 3:1, and borders of fields and icons in controls — also 3:1.

The difficulty is that checking text contrast against a static mockup lies: if an image, gradient, or semi-transparent layer sits under the label, the background beneath specific characters turns out lighter than the block average.

Then the cost kicks in. Unreadable text on a site is not a matter of aesthetics: the user does not understand what to enter in a field, cannot see exactly where the error is, cannot find the link to recover access.

They either leave or write to support, and feedback turns into a stream of identical questions instead of product data. On mobile, in sunlight, with low vision, or with reduced screen brightness, the readability margin is spent first.

Interface accessibility here is not a checkbox in a report but a requirement for the style system: color tokens, component states, rules for overriding them for specific consumers.

We examine exactly where the interface stops being readable and how to close this so the rule works on all new screens instead of being fixed manually on each one.

Readability, text scaling, and audience reach

Main text contrast below the 4.5:1 threshold is not a matter of taste. At that ratio, field labels, hints, and error messages blend into the background for people with low vision and for those reading from a phone in a bright room.

Bringing “text — background” pairs to 4.5:1, and large text and controls to 3:1, removes a whole class of failures in which a person physically cannot complete the scenario.

Font scaling is the second half of the task. A layout built on relative units withstands system zoom up to 200% without horizontal scrolling, clipped labels, or overlapping blocks.

Absolute values in pixels do not pass such a check, and a user who needs large text leaves, even though they came for a purpose.

Forms show the effect fastest. When labels are contrasty, field borders are distinguishable, and the error is shown not only by color but also by text next to the field, the share of abandoned applications falls: the person sees what is required and what is filled in incorrectly.

Support requests like “I can’t see the button,” “the text blends together” disappear as a category — the cause was not logic but readability. The freed-up time the team spends on developing scenarios, not on explaining where the payment button is.

A separate benefit is audience reach. A readable interface works equally for users with visual impairments, for those who access it from a phone outdoors, and for the older age group that increases font size in the browser.

Ways to bring contrast and typography up to standard

The audit begins with an inventory of “text — background” pairs and font sizes across screens. The threshold for body text is 4.5:1, for large type and graphical elements — 3:1, plus the requirement to preserve readability when scaling the interface up to 200%.

According to WCAG, violations almost always cluster into several patterns — this determines which fix will work.

Approaches do not replace one another: style configuration, component rework, and manual fine-tuning are applied in different order.

In practice, they start with style configuration: palette and scale in variables close most typical violations at once across all screens. Then components are reworked so the fix does not roll back in the next build. Manual fine-tuning remains for unique blocks.

The limitation of the approach: checks catch contrast but not readability — line length, letter spacing, and overflow when translated into another language, so interface typography still goes through an engineer. We lock the thresholds into check rules so regressions do not return.

How implementation goes: from audit to handoff

Implementing accessibility is not a one-time palette fix but a sequence of steps with a verifiable result at each. The goal is not only to raise WCAG contrast to the required level but also to lock in the rules so new screens do not repeat the same violations.

1. Interface inventory. We compile a list of templates, components, and their states — hover, focus, disabled, error. For each, we record text styles and backgrounds: without this list, measurements lose completeness.
2. Audit and measurement. We calculate the actual contrast ratio for all “text — background” pairs separately for small and large text, controls, and graphics. We mark everything below the required 4.5:1 and 3:1.
3. Review of disputed cases. Text over images, gradients, semi-transparent layers, and focus states are calculated incorrectly by automation — we check them manually, on real content.
4. Fix plan. For each group, we decide: change the shade in the palette, add a backing or outline, or limit the background under the text. We make fixes in design-system tokens, not in individual components — one change propagates across all screens.
5. Configuration and verification. We adjust the palette, typography, and tokens, set minimum font sizes and line spacing, and remove fixed block heights. Then we repeat the measurements and run regression across all templates, the dark theme, and the system high-contrast mode.
6. Documentation handoff. We hand over contrast and typography rules, a checklist for new components, and a description of checks in automated tests so accessibility does not roll back in the next release.

What the client receives: rules, styles, regulations

Fixing current screens is only half of the result of accessibility work. The second half is materials by which the client’s team itself checks new pages and does not lose contrast two releases later. We hand them over together with the code, not as a separate document “for reporting.”

• Theme variables. Colors and font sizes are moved into a set of variables: background, primary and secondary text, borders, hover and focus states. Changing the brand shade in one place no longer breaks neighboring screens.
• Contrast rules. A table of permitted combinations with thresholds for body text, large headings, controls, and icons. It separately marks where contrast can be lowered and where it cannot.
• Updated styles. Buttons, input fields, links, hints, and error messages are switched to theme variables and verified in all states — including focus, hover, and disabled.
• Verification regulations. A step-by-step procedure: which screens to review, what to measure with, what counts as a blocking violation and what is an acceptable exception, and how to document it.
• Guide for designers. How to choose a “background — text” pair and font sizes already in the mockup so the layout does not have to be reworked. With examples of permitted and prohibited combinations.
• Memo for editors. Limits on line length and font size, plus a ban on color as the sole carrier of meaning: a link inside a paragraph must differ by more than shade.
• Font scaling. Layout behavior when text is enlarged: what wraps, what gets clipped, where a different layout is needed, and how to check this before release.

Project case study: how accessibility failures were eliminated

The client is an application submission service with a personal account: about 240 screens, some on inherited templates. A contrast run according to the Web Content Accessibility Guidelines (WCAG) showed that 68 screens fail the check, and 31 are set in type below the base size.

The scanner produced 210 critical findings — and that is only for the key scenarios included in the sample.

What was changed in the implementation

Contrast was moved into theme tokens: instead of color codes inside components, “text/background” pairs verified for a 4.5:1 ratio for body text and 3:1 for large text, with separate values for hover and disabled states.

The typography scale was reduced to six sizes with a step from the base, and local type-size overrides in markup were prohibited — otherwise the next developer would again break what had already been fixed.

What the measurements showed

The share of screens passing automated checks grew from 72% to 100%: zero critical findings, with only isolated warnings remaining on translations.

The share of completed forms rose from 61% to 84% — people stopped abandoning completion at the step where field labels were gray on gray. Support requests with the wording “I can’t see the text” fell by a factor of three over the same period.

How do AA and AAA levels in WCAG differ, and which should you choose?

WCAG levels are not “a more expensive quality tier” but formal thresholds: A — the baseline minimum, AA — the industry standard referenced in requirements and tenders, AAA — extended.

The difference between them is measurable and primarily concerns requirements for text contrast and interface elements.

Level A is met almost automatically. AA requires rebuilding interface states: placeholders, disabled buttons, links within text, input field borders — they are most often set to gray “by eye,” and they fail the threshold during checking.

AAA raises the bar to 7:1: a brand accent almost never passes as text color, so it is left for backgrounds and large headings.

This level is rarely adopted for an entire site because it narrows the palette to a few verified pairs; selectively, it is used for long texts, forms, and sections where the audience reads for a long time.

Which level to choose: by default — AA; it covers legal requirements and does not break the visual style. AAA is enabled selectively — where there is a regulator or an audience with visual impairments.

Contrast checking is automated better than other criteria, but hover and focus states have to be verified manually — that is exactly where gaps remain.

Technical doubts about accessibility and font sizes

Accessibility questions almost always come down to the same thing: how to meet WCAG contrast requirements without diverging from the brand, and without rewriting from scratch what already works. Below are answers to what most often comes up during interface review.

We already have a component set implemented — do we have to redo everything?

No. Fixes go into the base layers: typography, buttons, input fields, links, hover and focus states. Other components inherit these values, so the change reaches them without manual editing. In effect, a few dozen lines in shared styles change, not the entire interface.

The brand font is thin and “falls apart” at small sizes. What should we do?

We look at the typeface metrics: x-height, letter spacing, weight. For thin variants, we raise the minimum size and weight and add line-height margin.

The text stops sticking together at increased zoom, while the font’s character is preserved in headings, where it works as intended.

How do you verify the result?

A manual pass over key screens plus automated checking in the build: it catches contrast and font sizes on new elements and prevents deviations from returning.

We additionally review the interface at increased zoom and on narrow screens — this shows where the layout breaks, not only where contrast is insufficient.

Let’s discuss the task and come back with an estimate and plan

To make the estimate accurate rather than approximate, a minimal set of source data is needed at the start. The more complete the package, the fewer assumptions in the implementation plan and the less often the scope of fixes changes mid-project.

• A list of pages and sections where text contrast and font sizes raise questions — including buttons, input fields, and error messages.
• Current color and typography values: a mockup, theme, or style sheet with variables.
• The target compliance level and requirements from your side or an external review, if they have already been formulated.
• Reports and screenshots of previous measurements — they show which findings have already been addressed.
• Access to the repository or a test environment: we check contrast and text scaling on live pages, not on a mockup copy.
• A list of supported browsers and devices, including mobile, and the scaling settings that need to be taken into account.
• Design constraints: brand colors and typefaces that cannot be changed — for them we select the closest permissible shades.

Next, we will cross-check the data, clarify a couple of details, and come back with an estimate, a phased implementation plan, and the scope of changes in styles and components.

Let’s discuss the task: we will review priorities, outline the order of work, and show exactly what you will receive as a result.