Typography Accessibility in CSS

What You Learn From This Page

• How font selection, size, weight, spacing, measure, and contrast affect reading.
• How to distinguish WCAG requirements from flexible design recommendations.
• How to support browser zoom, text resizing, reflow, and user spacing overrides.
• How to keep links, controls, forms, errors, headings, and dynamic content readable.
• How fonts, fallback metrics, dark mode, localization, and responsive layouts interact.
• How to test typography with automated tools and realistic manual checks.

Introduction

Typography accessibility means presenting text so that people can perceive, understand, enlarge, restyle, and interact with it under different visual, cognitive, language, device, and environmental conditions. It is not achieved by choosing one accessible font or setting body text to a particular number. Font design, size, weight, line height, line length, spacing, alignment, contrast, wrapping, semantics, and responsive layout all work together.

Accessible typography also respects adaptation. Users may zoom a page, increase only text size, apply a custom stylesheet, enlarge letter and word spacing, switch to high contrast, use a different default font, or read a translation much longer than the original copy. The interface must preserve content and functionality through those changes rather than requiring exact authored metrics.

Accessibility Is More Than Visual Style

A heading can look large and bold while remaining a plain <div> with no document meaning. A red sentence can look like an error while providing no text or programmatic indication of error. A tiny link can technically be readable yet remain difficult to locate and activate. Typography accessibility therefore combines CSS presentation with semantic HTML, meaningful content, and usable interaction.

CSS should reinforce the structure and meaning already present in the document. It cannot repair an incorrect heading hierarchy, a missing form label, or instructions conveyed only by color.

Who Benefits From Accessible Typography?

People with low vision, color-vision differences, dyslexia, cognitive disabilities, age-related vision changes, migraines, motor disabilities, and situational limitations can all benefit. So can readers using a small phone, a low-quality screen, bright sunlight, a translated interface, or a browser with customized text settings.

Designing for this range improves ordinary reading as well. Clear hierarchy, comfortable lines, visible links, and resilient controls reduce effort for everyone.

Choose Readable Font Families

A readable font has distinguishable character shapes, usable spacing, appropriate stroke contrast, and solid rendering at the sizes where it will appear. Characters such as uppercase I, lowercase l, digit 1, uppercase O, and digit 0 should remain distinguishable in contexts where confusion matters.

body {
  font-family: system-ui, "Segoe UI", Arial, sans-serif;
}

No single typeface is universally accessible. Evaluate real paragraphs, controls, numbers, punctuation, and supported scripts rather than relying on a category label such as sans serif.

Avoid Decorative Fonts for Body Copy

Decorative display faces can support short branding or editorial headings, but unusual shapes and dense details become tiring across paragraphs. Script fonts, extreme contrast, compressed widths, and novelty letterforms can slow character recognition at smaller sizes.

Use a readable body family and reserve expressive type for short, noncritical roles. Never use typography that makes users decode the visual style before they can understand the words.

Build a Robust Font Stack

Web fonts can fail because of network conditions, content blockers, cache problems, unsupported formats, or configuration errors. A fallback stack should preserve readability and approximate the intended metrics closely enough that text does not overlap or disappear.

body {
  font-family: "Inter", system-ui, "Segoe UI", Arial, sans-serif;
}

Test the page with the primary font blocked. Confirm that headings wrap acceptably, buttons grow, tables remain usable, and icons are not encoded as private font glyphs without accessible alternatives.

Provide Fonts for Every Supported Script

A Latin-focused web font may fall back for Tamil, Arabic, Hindi, Japanese, or other scripts. The fallback can have different x-height, width, weight, and line metrics. A design that fits only the Latin font can clip translated content or create inconsistent baselines.

Define language-aware stacks where needed and test each supported script with native readers. Correct glyph coverage is only the beginning; the font must also be readable and culturally appropriate.

Use a Comfortable Starting Font Size

A body size of 1rem is a common starting point because it normally follows the browser's root size and user preferences. It is not a universal WCAG minimum, and it should not be treated as a guarantee that every font is equally readable. Apparent size varies with x-height, width, weight, rendering, and viewing conditions.

body {
  font-size: 1rem;
}

Evaluate actual content and avoid shrinking secondary text until it becomes difficult to read. Metadata can be visually quieter through color, weight, and placement without becoming tiny.

Prefer Relative Units

Root-relative rem units help establish a consistent scale that responds to the root size. em units are useful when a component should scale from its own text size. Percentages can also preserve relationships. Pixel units are not automatically inaccessible, but rigid systems often make adaptation harder.

body { font-size: 1rem; }
h1 { font-size: 2.5rem; }
.button { padding: 0.75em 1.25em; }

Select units according to the desired relationship. Test user font-size preferences and browser zoom rather than assuming relative units alone guarantee success.

Respect the Browser Root Size

Resetting the root to a small percentage or an arbitrary pixel value can undermine user expectations and make rem calculations less transparent. Leaving the default alone or using 100% preserves the browser's configured baseline.

html {
  font-size: 100%;
}

A design system can still define a rich type scale without converting the root into a calculator trick. Readability and adaptability matter more than convenient mental arithmetic.

Use Comfortable Line Height

Line height creates vertical separation between lines and helps the eye move from the end of one line to the beginning of the next. Body copy often benefits from a unitless value around 1.4 to 1.7 as a design starting range, depending on the font, size, measure, and language. This range is guidance, not a universal conformance threshold.

article {
  line-height: 1.6;
}

Dense interfaces may use slightly tighter values, while long reading content may need more air. Test actual paragraphs rather than judging one line in isolation.

Why Unitless line-height Is Useful

A unitless line height multiplies each descendant element's own font size. If a heading inherits 1.5, its used line height grows with the heading instead of inheriting a fixed pixel distance designed for body text.

body {
  line-height: 1.5;
}

This behavior makes a shared baseline more resilient. Individual display headings can still use a tighter tested value where their size and short length justify it.

Heading Line Height

Large headings often need a tighter line height because their glyphs and visual gaps are already large. Values around 1.1 to 1.3 can be reasonable starting points, but descenders, accents, wrapped lines, and script-specific marks must remain clear.

h1 {
  line-height: 1.15;
}

Never use a line height so tight that glyphs overlap. Test long headings and translations that wrap to three or more lines.

Keep Line Length Comfortable

Very long lines make it difficult to locate the start of the next line, while very short lines create excessive interruptions and vertical movement. A measure around 45 to 75 characters is a common editorial starting point, not a WCAG pass/fail rule. The appropriate range depends on typeface, size, line height, language, and content complexity.

article {
  max-inline-size: 65ch;
}

The ch unit provides a font-relative approximation that is useful for measure, but it is not an exact character count for proportional text.

Avoid Full-Width Prose on Large Screens

A paragraph stretched across a wide monitor can contain far more words per line than a reader can track comfortably. Constrain the reading column while allowing surrounding page sections, tables, or media to use appropriate wider layouts.

.article {
  inline-size: min(100% - 2rem, 68ch);
  margin-inline: auto;
}

At narrow widths, the article still fills the available space with safe inline padding. At wide widths, its measure remains controlled.

Text Contrast Requirements

WCAG 2.2 Level AA requires a contrast ratio of at least 4.5:1 for ordinary text and images of text. Qualifying large-scale text has a minimum of 3:1. The large-text definition depends on size and weight, so teams should calculate against the criterion rather than relying on visual judgment.

body {
  color: #1f2937;
  background: #ffffff;
}

Contrast is based on relative luminance, not a simple color-name difference. Test actual foreground and background colors, including transparency and imagery behind text.

Contrast Is a Minimum, Not a Target

A combination barely meeting the threshold may still be difficult under glare, low-quality displays, thin font weights, or small sizes. Use comfortably readable contrast for body content and avoid treating the minimum ratio as an optimization goal.

At the same time, extreme contrast can be uncomfortable for some readers in dark interfaces. Offer well-tested themes and let users choose where practical, while ensuring each theme satisfies applicable requirements.

Test Every Text State

Placeholder text, disabled controls, visited links, errors, helper text, badges, selected tabs, focus states, and text over images all need review. A base body color passing contrast does not validate every component state.

Disabled or inactive interface text can have different criterion treatment, but it should not be used to display information that users still need to understand. Avoid making important read-only text look disabled merely to reduce visual emphasis.

Do Not Rely on Color Alone

Color can reinforce meaning but should not be the only indicator. An error can include the word "Error," a specific message, an icon with an accessible treatment, and association with the affected field. A chart can combine color with labels, shapes, or patterns.

<p class="field-error" id="password-error">
  Error: Password must contain at least 8 characters.
</p>

Clear wording is part of typography accessibility because users need more than a red visual change to understand what happened and what to do next.

Keep Links Visibly Identifiable

Inline links should be distinguishable from surrounding text without requiring pointer hover. An underline provides a familiar non-color cue and survives many display conditions. Removing all underlines globally can leave users searching for interactive text.

.prose a {
  color: #075985;
  text-decoration: underline;
  text-decoration-thickness: 0.08em;
  text-underline-offset: 0.15em;
}

Navigation links may use context, layout, or selected-state styling, but they still need visible hover, focus, and current-page feedback.

Focus Styling and Typography

An underline identifies a link; a focus indicator identifies the control currently receiving keyboard input. Do not remove browser outlines without an equally visible replacement. Ensure focus rings are not clipped by text wrappers with hidden overflow.

a:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

Test focus across light, dark, forced-color, and high-zoom layouts. Sticky headers should not obscure the focused link.

Use Letter Spacing Carefully

Body text is usually strongest at the font's normal tracking. Large positive spacing breaks familiar word shapes and increases line length; negative spacing can cause glyph collisions. Short uppercase labels may benefit from modest positive tracking because uppercase words appear denser.

.category-label {
  text-transform: uppercase;
  letter-spacing: 0.06em;
}

Test every value with the actual font, weight, size, language, and fallback stack.

Avoid Excessive Word Spacing

Large word gaps disrupt phrase grouping and create visible rivers through paragraphs. Negative spacing can make separate words appear joined. Most body text should keep word-spacing: normal and allow the font and browser to provide natural rhythm.

Justified text can introduce additional spacing changes, so test it at narrow widths and across languages. Start alignment is usually a safer web default.

Avoid Long All-Caps Text

All-uppercase paragraphs remove familiar lowercase word shapes and can feel visually loud. They also expand text in some languages and can produce unexpected results through locale-sensitive transformations. Use uppercase selectively for brief labels or categories.

Do not type semantic content in uppercase merely for appearance. Keep normal source casing and use CSS only where the visual treatment is appropriate.

Select Font Weight Deliberately

Very thin strokes can disappear on lower-quality screens, under glare, or at small sizes. Extremely heavy body text can close internal spaces and reduce sustained readability. A regular weight around 400 is a common body baseline, but actual appearance varies by family.

body { font-weight: 400; }
h1, h2 { font-weight: 700; }
strong { font-weight: 700; }

Confirm that requested weights exist. A browser-synthesized bold or light face may not match the intended readability.

Do Not Make Everything Bold

Emphasis works through contrast with surrounding content. If every sentence, label, and button uses a heavy weight, readers lose the hierarchy that tells them where to begin and what matters.

Use weight alongside size, spacing, position, and semantic structure. Reserve strong emphasis for genuinely important phrases rather than compensating for weak content organization.

Use Semantic Emphasis

When emphasis contributes meaning, use <strong> or <em> rather than a generic span styled bold or italic. CSS controls appearance, while semantic markup preserves intent for assistive technology and alternate styles.

<p><strong>Important:</strong> Save your recovery code.</p>

Not every bold phrase needs strong semantics, but meaning should not exist only in a class name.

Align Long Text to Its Reading Start

Long centered paragraphs make the start of each line move horizontally, increasing scanning effort. Right-aligned left-to-right prose has the same problem. Use logical start alignment for body text so it follows the writing direction.

article {
  text-align: start;
}

Center alignment remains useful for short titles, taglines, and compact empty states. Test any centered text that can wrap beyond two or three lines.

Use Logical Alignment

start and end follow the inline direction, unlike physical left and right values. Logical alignment supports right-to-left and vertical writing more naturally and reduces localization overrides.

Use accurate lang and dir attributes. CSS alignment cannot substitute for correct language and bidirectional semantics.

Use Justification Carefully

Justification can create large gaps and rivers of whitespace, particularly in narrow columns or languages without suitable hyphenation. Those gaps can disrupt reading and word grouping. Browser algorithms also vary by writing system and available language information.

Prefer start alignment for most responsive web content. If editorial requirements call for justification, use comfortable measure, correct language metadata, and extensive narrow-width testing.

Allow Text to Wrap

Global no-wrap rules break mobile layouts and high-zoom experiences. Buttons, navigation, tables, cards, and labels must either wrap, grow, reflow, or expose a complete alternative. A clean one-line screenshot is not evidence that a component is robust.

.message {
  white-space: normal;
  overflow-wrap: anywhere;
}

Use no-wrap only for short content with a genuine single-line requirement and a tested overflow strategy.

Do Not Truncate Critical Text

Ellipsis can hide the part of an error, instruction, warning, or legal statement that tells users what action to take. Allow critical content to wrap fully and give its container natural height.

Truncation is more appropriate for secondary card titles, file names, usernames, or breadcrumbs when the full value remains available through a destination or accessible disclosure.

Support Text Resize to 200 Percent

WCAG 2.2 Success Criterion 1.4.4 requires text, except captions and images of text, to be resizable up to 200 percent without loss of content or functionality. This includes labels and text inside controls, not only article paragraphs.

Test incremental zoom or text-size steps. Look for clipping, overlapping, missing actions, off-screen dialogs, and components that shrink text at a breakpoint to cancel the user's enlargement.

Support Reflow

WCAG 2.2 Reflow requires non-excepted vertically scrolling content to work at a width equivalent to 320 CSS pixels without loss of information or functionality and without two-dimensional scrolling. This corresponds to a 1280 CSS-pixel viewport at 400 percent zoom.

Typography and layout must cooperate: text wraps, columns stack, controls move, and sticky regions stop consuming most of the viewport. Data tables and content whose meaning requires two dimensions need deliberate handling under the criterion's exception.

Avoid Fixed Heights Around Text

A fixed-height card, alert, or button may fit default text and clip content after zoom, translation, or spacing changes. Use natural block size or a minimum height and allow the component to grow.

.notice {
  min-block-size: 6rem;
  padding: 1rem;
}

If a component must remain compact, provide an accessible expansion mechanism rather than hiding essential words.

Let Buttons Grow

Buttons need readable labels and usable target areas. Padding in em units can scale with text, while a minimum block size protects the control's baseline dimensions. Avoid fixed width and height combinations that assume one short language.

.button {
  min-block-size: 2.75rem;
  padding: 0.75em 1.25em;
  line-height: 1.2;
  white-space: normal;
}

Test labels such as "Save" alongside realistic long actions such as "Save and Continue to Payment."

Use Responsive Typography Carefully

The clamp() function can define a minimum, fluid preference, and maximum. It is useful for display headings that should adapt without becoming extremely small or large.

h1 {
  font-size: clamp(2rem, 1.5rem + 3vw, 4rem);
}

Do not rely on viewport units alone because text can become tiny on narrow screens or enormous on wide displays. Test browser zoom to ensure breakpoint rules do not undermine user enlargement.

Preserve User Text Spacing

WCAG 2.2 Success Criterion 1.4.12 requires applicable content to remain usable when users override line height to at least 1.5 times font size, paragraph spacing to at least 2 times font size, letter spacing to at least 0.12 times font size, and word spacing to at least 0.16 times font size.

The criterion does not require those values as the default design. It requires no loss of content or functionality when they are applied. Flexible containers, wrapping, and natural height make that adaptation possible.

Common Text-Spacing Failures

Fixed-height buttons can cut off wrapped labels. Absolutely positioned text can overlap adjacent content. Hidden overflow can remove the final line. Tight cards can cover their actions. Single-line navigation can become wider than the viewport.

Test the complete spacing override set together because combined expansion reveals failures that individual property changes may not expose.

Avoid Images of Text

WCAG 2.2 Images of Text encourages real text when the same visual presentation can be achieved with available technology, except where the image can be customized or the presentation is essential. Real text can resize, reflow, translate, adapt to themes, and respond to user styles.

Logotypes are treated as essential under the criterion, and text that is incidental within a larger meaningful picture is addressed differently. Provide appropriate alternative text for informative images regardless.

Use Semantic Heading Structure

Heading levels describe document hierarchy. Choose them according to section relationships, then style them to the desired size. Do not use <h6> merely because the text should look small or a generic div because the heading should look unusual.

<h1>Account Settings</h1>
<h2>Security</h2>
<h3>Recovery Codes</h3>

A meaningful outline helps screen-reader navigation, search, comprehension, and maintenance.

Make Form Labels Persistent

Placeholder text disappears as users type and often has low contrast. It is not a replacement for a visible, programmatically associated label. Keep labels readable and available throughout the interaction.

<label for="email">Email address</label>
<input id="email" type="email" placeholder="name@example.com">

Use helper text for format guidance and associate errors with their fields. Avoid tiny uppercase labels that depend on letter spacing for legibility.

Write Actionable Error Messages

"Invalid" does not tell users what failed or how to recover. State the field, requirement, and corrective action in plain language. Let the message wrap and maintain sufficient contrast.

.field-error {
  font-size: 0.9375rem;
  line-height: 1.45;
  color: #991b1b;
}

Color can reinforce the state, but the wording must stand on its own.

Keep Text Visible During Font Loading

Users should not wait for a decorative font before they can read content. A suitable font-display strategy can show fallback text during loading, while a robust stack maintains legibility if the font never arrives.

@font-face {
  font-family: "Example Sans";
  src: url("example-sans.woff2") format("woff2");
  font-display: swap;
}

Choose the strategy according to product needs and test slow networks. Availability is part of accessibility.

Control Layout Shift From Font Swaps

Different font metrics change line breaks, element heights, and control widths. A late swap can move a button as the user tries to activate it or convert a two-line heading into three lines inside a fixed container.

Choose metrically compatible fallbacks, keep dimensions flexible, preload only critical resources responsibly, and test the full loading sequence rather than only the final rendered state.

Support Dark and Forced-Color Modes

Colors that pass in a light theme may fail in a dark theme. Semi-transparent text can blend unpredictably with layered backgrounds. Forced-color modes may replace authored colors and expose assumptions built into decorative underlines or icons.

:root {
  color-scheme: light dark;
  --text: #1f2937;
  --surface: #ffffff;
}

Test every theme independently and verify that semantic states do not depend on subtle color differences.

Typography in Tables and Dashboards

Dense interfaces tempt teams to shrink text and compress line height. Instead, prioritize the data users compare, use tabular figures for numeric columns where appropriate, allow headers to wrap, and provide responsive alternatives for secondary columns.

Do not reduce labels below practical readability merely to avoid horizontal scrolling. Some structured data genuinely needs a controlled scroll region, while simpler tables can reflow into labeled records.

Typography in Notifications and Toasts

Transient messages need concise text, readable contrast, sufficient display time, and a layout that expands for translations and increased text size. Avoid fixed heights and line clamps that hide recovery actions.

If a message requires sustained reading or interaction, a persistent inline alert or dialog may be more appropriate than a disappearing toast.

Create a Typography System

Design tokens can centralize text roles, sizes, line heights, weights, and measures. Role-based names such as body, caption, label, and display communicate intent more clearly than arbitrary numbers.

:root {
  --text-sm: 0.875rem;
  --text-base: 1rem;
  --text-lg: 1.25rem;
  --leading-tight: 1.2;
  --leading-body: 1.6;
  --measure-reading: 68ch;
}

Tokens improve consistency but do not replace testing. A role can still be inaccessible if used on the wrong background or inside an inflexible component.

An Accessible Article Baseline

A strong reading surface uses a legible family, root-relative size, comfortable unitless line height, logical start alignment, controlled measure, visible links, and flexible width.

.article {
  inline-size: min(100% - 2rem, 68ch);
  margin-inline: auto;
  font-size: 1rem;
  line-height: 1.65;
  text-align: start;
  letter-spacing: normal;
  word-spacing: normal;
}

This is a baseline, not a formula. Adjust it for the chosen font, language, audience, and content while preserving adaptation.

An Accessible Form Baseline

Form typography should keep labels persistent, inputs at inherited readable sizes, instructions close to their controls, and errors explicit. Padding should scale, and fields should remain usable at zoom.

label {
  display: block;
  margin-block-end: 0.5rem;
  font-size: 0.9375rem;
  font-weight: 600;
}

input {
  box-sizing: border-box;
  inline-size: 100%;
  padding: 0.75em 1em;
  font: inherit;
}

Do not shrink input text to fit a fixed control. Let the control and surrounding layout respond.

Common Mistake: Tiny Secondary Text

Captions and metadata are often reduced until they are barely readable. Use hierarchy through placement, color with sufficient contrast, and moderate weight before relying on extreme size reduction.

Common Mistake: Thin Gray Text

A thin font weight combined with pale gray may technically resemble a minimalist design but fail real reading conditions. Contrast tools measure colors, not the practical disappearance of hairline strokes, so review rendered text at actual size and on multiple displays.

Common Mistake: Fixed Pixel Containers

Exact widths and heights built around one string collapse under zoom, spacing overrides, and translation. Use content-driven dimensions, minimums, maximums, wrapping, and responsive reflow.

Common Mistake: Disabling Zoom

Viewport configurations that restrict user scaling prevent people from enlarging text and content. Use a standard responsive viewport and allow browser zoom. Solve layout failures rather than blocking adaptation.

Common Mistake: CSS-Only Meaning

Bold, red, uppercase, italic, or crossed-out text can imply meaning visually without exposing it programmatically. Use semantic elements, labels, status wording, and ARIA only where native HTML cannot express the relationship.

Common Mistake: Testing Only One String

"Save" does not represent translated actions, user names, legal descriptions, or validation guidance. Populate components with shortest, longest, empty, multiline, and unexpected content before approving the typography.

Manual Testing Strategy

Zoom to 200 percent and continue to 400 percent for reflow testing where applicable. Increase browser default text size, apply the WCAG text-spacing overrides, switch themes, enable forced colors, block web fonts, and navigate entirely by keyboard.

Review small and large viewports, split-screen containers, print preview, PDF output, and actual mobile devices. Check whether every word, label, action, focus indicator, and status remains available.

Language and Content Testing

Test English alongside supported languages with different scripts and expansion patterns. Include mixed-direction content, long compound words, diacritics, combining marks, numbers, punctuation, and fallback glyphs.

Native readers should review readability and cultural typography. Automated screenshots cannot determine whether a line-break rule or typeface feels appropriate in every language.

Automated Testing and Its Limits

Automated accessibility tools can detect many contrast failures, missing labels, structural problems, and some viewport issues. Visual regression tests can catch overlaps after text changes. Browser automation can apply spacing overrides and inspect clipping.

No tool can fully judge reading comfort, font suitability, hierarchy, wording, or whether truncation hides a critical distinction. Combine automation with manual review and user research.

Typography Accessibility Reference

Common Interview Questions

What is typography accessibility? It is the design and implementation of text so it remains readable, understandable, adaptable, and usable across users, settings, languages, and devices.

Why use relative units? They express scalable relationships and can cooperate with user and browser sizing preferences.

Is 16 pixels a WCAG minimum body size? No. One rem near the browser default is a common design starting point, not a universal WCAG minimum.

What contrast does ordinary text need at Level AA? At least 4.5:1, while qualifying large-scale text has a 3:1 minimum.

Why use unitless line height? It scales from each element's own font size and avoids passing a fixed line box through descendants.

Why avoid fixed heights? Enlarged, translated, wrapped, or respaced text can be clipped or overlap other content.

Why keep links underlined? Underlining gives a familiar non-color indication that text is interactive.

Why is start alignment useful? It follows the writing direction and supports internationalized layouts better than physical left alignment.

What does WCAG text spacing require? Content must remain functional and visible when users apply the criterion's specified line, paragraph, letter, and word spacing values.

Can automated tools prove typography is accessible? No. They help detect measurable problems but cannot fully judge readability, hierarchy, wording, or content suitability.

Practical Review Checklist

• Choose readable fonts with robust fallback coverage.
• Use scalable sizing without overriding user defaults unnecessarily.
• Use comfortable unitless line height and controlled reading measure.
• Meet contrast requirements in every theme and component state.
• Keep inline links identifiable and keyboard focus visible.
• Use semantic headings, emphasis, labels, and status messages.
• Allow important content and controls to wrap and grow.
• Avoid fixed-height text containers and CSS-only meaning.
• Support 200 percent text resize and applicable reflow requirements.
• Tolerate WCAG text-spacing overrides without clipping or overlap.
• Test web-font failure, dark mode, forced colors, and exports.
• Test long content, multiple languages, zoom, and real devices.

Key Takeaway

Accessible typography is a resilient system, not a single font or number. Readable type, scalable sizing, comfortable line height, controlled measure, sufficient contrast, visible links, semantic structure, and natural wrapping create the baseline. Flexible containers and responsive layouts preserve that baseline when users enlarge or restyle text.

Treat WCAG values as precise requirements where they apply and design heuristics as starting points to test with real readers. The strongest implementation survives font failure, translation, dark mode, high zoom, text-spacing overrides, narrow containers, and document export without hiding content or functionality. Text succeeds when readers can adapt it to their needs and still understand and operate the page.