Color and typography affect whether people can perceive, distinguish, and read content. A theme must remain usable for people with low vision, color vision differences, reading disabilities, and user-defined display settings.
Test the rendered site in every supported theme and state. A palette, CSS variable, or automated result is not evidence that every actual color combination is accessible.
For a site targeting WCAG 2.2 AA:
These requirements apply to text in all states, including links, placeholders, validation messages, disabled-looking controls that remain operable, hover content, and keyboard focus content. Evaluate text over gradients, images, transparency, and overlays against the least contrasting background it can cover.
WCAG's enhanced contrast ratios are 7:1 for normal text and 4.5:1 for large-scale text at Level AAA. Treat these as aspirational when the project target is AA. They may become a product requirement when research shows that the audience or conditions need stronger contrast.
Visual information needed to identify or operate a user interface component must have at least 3:1 contrast against adjacent colors. This includes boundaries, icons, checkmarks, selected states, and focus indicators when those visual features are necessary to understand the component.
Graphical objects and parts of graphics needed to understand the content also need at least 3:1 contrast against adjacent colors. This does not mean every color in an illustration must meet 3:1. It applies to the visual information people need.
Do not rely on a faint border as the only indication of an input if the border does not meet non-text contrast. Native controls can provide useful platform behavior, but test them after applying theme styles.
Color can reinforce meaning but cannot be the only way to communicate it. Add text, an icon with an accessible name, a pattern, a border, or another visual difference.
Define colors by purpose, such as text, background, border, link, error, focus, and selected state. Reuse semantic CSS custom properties rather than repeating unrelated color values. This makes the system easier to review and change.
Test every foreground and background combination that can actually occur. Include:
Changing one shared color token can create failures in many components. Review token changes across the complete component set rather than approving a single sample.
A dark theme is not an inverted light theme. Define and test each color pair and each component state in both schemes.
Use prefers-color-scheme or the CSS light-dark() function to respect the user's system preference. The light-dark() function requires an appropriate color-scheme value. If the site offers its own theme control, make it a properly labelled control, retain the user's choice, and avoid overriding an explicit selection with a system preference.
The CSS contrast-color() function can choose black or white based on a background. It does not remove the need for testing. Mid-tone backgrounds can still produce an inadequate result, and older browsers may not support the function. Use it as progressive enhancement with tested fallback values.
Do not assume a light or dark palette meets WCAG because it is generated automatically. Test text, controls, focus indicators, icons, charts, syntax highlighting, and status colors in each scheme.
Forced colors mode replaces many author colors with a user-selected system palette. Let the browser make these substitutions. Use the forced-colors media feature only for small corrections when content or controls otherwise disappear.
forced-color-adjust: none unless the exception is narrow, necessary, and tested.There is no single accessible font family. Choose typefaces with clear letterforms, adequate weight, and distinguishable characters. Test uppercase I, lowercase l, the number 1, uppercase O, and the number 0. Avoid thin weights and decorative typefaces for extended reading.
Use real text rather than images of text. Real text can resize, reflow, translate, and adapt to user settings. See Accessible images and media for the limited exceptions and alternative-text requirements.
WCAG does not specify a minimum body-text size. Start with a comfortable default and use relative units such as rem where they support consistent scaling. Do not block browser zoom or text resizing. Test the result rather than treating a unit choice as compliance.
Use a line height and paragraph spacing that support reading without separating related content. A unitless line height near 1.5 is a reasonable starting point for body text, not a universal requirement. Check the actual typeface, language, line length, and component.
Avoid long passages in all capitals, italics, or unusually light weights. Do not use font weight as a substitute for adequate size and contrast.
People may override line height, paragraph spacing, letter spacing, and word spacing. Content must remain readable and operable when text spacing is changed to the WCAG test values:
These are test values, not required default design settings. Do not clip, overlap, hide, or truncate text when users apply them. Avoid fixed-height text containers and layouts that depend on a precise number of lines.
Text must resize to 200% without loss of content or functionality. At 400% browser zoom in a 1280 CSS-pixel-wide viewport, content should reflow to the equivalent of a 320 CSS-pixel-wide viewport without two-dimensional scrolling, except where a two-dimensional layout is necessary for meaning or use.
Use flexible layouts, wrapping, and relative sizing. Check navigation, dialogs, tables, code, form controls, status messages, and content created by authors. Do not hide content at high zoom as a substitute for making it reflow.
WCAG's Level AAA visual-presentation guidance includes limiting text width to 80 characters or glyphs, or 40 where the writing system uses Chinese, Japanese, or Korean glyphs, avoiding full justification, and allowing users to select foreground and background colors. These are aspirational under an AA target. For long-form content, a moderate line length and start-aligned text are usually more readable and easier to maintain.
Automated tools can calculate some contrast pairs and detect some fixed-layout failures. They cannot determine whether color is the only cue, whether typography is comfortable to read, or whether every dynamic state has been tested.