Screen Readers and Typography: What You Need to Know

Typography, as a discipline, concerns itself with visual communication: how text looks on a page or screen. Screen readers, by definition, bypass visual rendering entirely — they process the DOM and deliver content to users through speech synthesis or refreshable braille displays. You might conclude, then, that typography has no relationship to screen reader accessibility.

This conclusion is wrong, and misunderstanding the relationship leads to real accessibility failures. Typography decisions — heading structure, icon font usage, language attributes, semantic HTML choices — directly determine what a screen reader user hears. More precisely, the relationship runs in both directions: typographic decisions shape the DOM structure that screen readers parse, and screen reader behavior should shape some typographic decisions.

What Screen Readers See (and Don't See)

Screen readers access content through the accessibility tree — a structured representation of the DOM that browsers build from HTML semantics, ARIA attributes, and CSS state. The accessibility tree is not the DOM, and it is not the visual rendering. It is a separate representation that filters and reorganizes content according to accessibility semantics.

Key things screen readers do not see:

CSS content property values are often not announced. Content added via ::before and ::after pseudo-elements using the CSS content property has inconsistent screen reader support. In most current screen reader and browser combinations, generated text content is announced — but the behavior has historically been unreliable enough that you should not rely on CSS-generated content for meaningful information.

/* Generated content — do not use for meaningful text */
.warning::before {
  content: "Warning: "; /* May or may not be read */
}

/* Better: use real HTML */
/* <span class="sr-only">Warning: </span><span class="warning-text"> */

Visual size and weight do not automatically carry semantic meaning. Text styled in 48px bold is not announced as a heading unless it uses heading HTML elements (h1–h6). Text styled in italic is not announced as emphasized unless it uses <em>. This is the core mapping between typography and semantics: visual styling must correspond to semantic HTML.

CSS display: none and visibility: hidden hide content from screen readers as well as visual users. This is intentional behavior — use it when content should be hidden from everyone.

opacity: 0 — unlike display:none — does not hide content from the accessibility tree. Screen readers will still announce opacity:0 content. This is a common source of confusion.

font-size: 0 — sometimes used to visually hide text while keeping it screen-reader accessible — does work for this purpose in most current implementations, but it is fragile. The more reliable approach for screen-reader-only text is:

/* Robust screen-reader-only class */
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

/* Allows element to become visible on focus — for skip links */
.sr-only-focusable:focus {
  position: static;
  width: auto;
  height: auto;
  padding: inherit;
  margin: inherit;
  overflow: visible;
  clip: auto;
  white-space: normal;
}

Heading Hierarchy and Document Structure

For screen reader users, heading elements (h1–h6) are primary navigation tools. NVDA, JAWS, VoiceOver, and TalkBack all allow users to jump between headings using keyboard shortcuts — this is how many screen reader users navigate long pages without reading everything linearly.

The heading hierarchy must be logical and consistent. WCAG 2.4.6 (AA) requires headings to be "descriptive" — actually describing the content they introduce. Poor heading structure is one of the most commonly reported barriers by screen reader users.

Rules for accessible heading hierarchy:

1. One h1 per page. The h1 is the document title — the primary topic. Multiple h1 elements create ambiguity about what the page is about.

2. Do not skip heading levels. Moving from h2 to h4 skips h3, which many screen reader users interpret as an error or structural inconsistency. Every level between the parent and child heading should exist.

3. Headings must describe their section. Vague headings like "More information" or "Details" are not helpful for navigation. A screen reader user jumping to headings needs to understand each section's topic from the heading alone.

4. Visual appearance must match semantic level. This is the typographic connection. If you style an h3 to look like an h2 for visual reasons — using CSS to change its size — the screen reader still announces it as level 3. Users expecting the visual hierarchy to match the semantic hierarchy will be confused.

<!-- Poor structure — skips h3, visual style doesn't match semantics -->
<h1>Product Documentation</h1>
<h2>Getting Started</h2>
<h4>Prerequisites</h4>  <!-- Skips h3 -->

<!-- Good structure — consistent hierarchy -->
<h1>Product Documentation</h1>
<h2>Getting Started</h2>
<h3>Prerequisites</h3>
<h3>Installation</h3>
<h2>Configuration</h2>
<h3>Basic Options</h3>

/* Styling headings to match visual design without breaking semantic order */
/* If h3 needs to look visually larger in a specific context: */
.sidebar h3 {
  font-size: 1rem; /* Visually smaller than main content h3 */
}

/* Better: use CSS classes to modify appearance, not wrong semantic levels */
.section-label {
  font-size: 0.875rem;
  font-weight: 600;
  text-transform: uppercase;
  letter-spacing: 0.05em;
}

When visual design requirements conflict with semantic hierarchy — a common occurrence in modern UI — the resolution is always to use the semantically correct heading level and adjust visual appearance with CSS, not to use the wrong heading level.

ARIA can help in specific situations. The role="heading" with aria-level attribute allows non-heading elements to be announced as headings, and aria-labelledby can associate labels with sections. But these are tools for specific edge cases — they cannot substitute for a thoughtful semantic heading structure.

Icon Fonts and Accessibility

Icon fonts are a widespread typographic accessibility minefield. Libraries like Font Awesome, Material Icons, and similar tools work by mapping private-use Unicode code points to glyph images. To render a shopping cart icon, you add a character like  which the icon font maps to the cart image. The result is visually correct but semantically empty — or worse, actively confusing.

Screen readers handle icon font characters inconsistently:

• Some screen reader and browser combinations read the underlying Unicode character name (usually meaningless to the user: "BLACK RIGHTWARDS ARROW" or similar)
• Some read nothing (when the Unicode point is in the private use area)
• Some read the CSS content value added by ::before pseudo-elements

None of these behaviors reliably deliver the intended meaning to the user.

The correct approach depends on whether the icon is decorative or meaningful:

Decorative icons (icons that accompany visible text and add no additional information):

<!-- Icon font with aria-hidden — screen readers skip it -->
<button>
  <i class="fas fa-search" aria-hidden="true"></i>
  Search
</button>

<!-- SVG icon — same approach -->
<button>
  <svg aria-hidden="true" focusable="false">
    <use href="#icon-search"></use>
  </svg>
  Search
</button>

Meaningful icons (icons that are the only visual indicator of an action or meaning):

<!-- Icon-only button — must have accessible label -->
<button aria-label="Search">
  <i class="fas fa-search" aria-hidden="true"></i>
</button>

<!-- Alternative: visible sr-only text -->
<button>
  <i class="fas fa-search" aria-hidden="true"></i>
  <span class="sr-only">Search</span>
</button>

SVG icons are generally preferable to icon fonts from an accessibility perspective because they have more reliable and consistent screen reader behavior, and the <title> and <desc> elements provide accessible descriptions:

<svg role="img" aria-labelledby="icon-title">
  <title id="icon-title">Search</title>
  <path d="..."/>
</svg>

If you are using a font like Material Symbols — which Google has moved toward ligature-based icons rather than PUA code points — the icon renders from text like "search" that is then styled as an icon glyph. This requires aria-hidden="true" on the icon element and an accessible label elsewhere, because the text "search" in the DOM would be read aloud literally.

Language Attributes for Multi-lingual Content

Screen readers synthesize speech using language-specific voices. A French text-to-speech engine has different phonological rules than an English one — and applying English pronunciation rules to French text produces output that is difficult or impossible for a French speaker to understand.

The lang attribute on the <html> element sets the primary language for the document. Screen readers use this to select the appropriate voice:

<!DOCTYPE html>
<html lang="en">

When content switches language within a document — a French quote in an English article, a product name in Japanese, a multi-lingual navigation — the lang attribute should be applied to the relevant element:

<p>
  The French call this concept
  <span lang="fr">raison d'être</span>,
  meaning reason for being.
</p>

<blockquote lang="de" cite="...">
  <p>Was mich nicht umbringt, macht mich stärker.</p>
</blockquote>

This is WCAG Success Criterion 3.1.2 (Language of Parts, Level AA). It is commonly missed on sites with internationalized content, and the user experience impact for screen reader users reading in their native language is significant.

From a typographic perspective, language attributes also affect text rendering:

/* Language-specific typographic rules using CSS :lang() */
:lang(ar) {
  font-family: 'Noto Sans Arabic', sans-serif;
  direction: rtl;
  text-align: right;
}

:lang(ja) {
  font-family: 'Noto Sans JP', 'Hiragino Kaku Gothic Pro', sans-serif;
  line-height: 1.8; /* CJK text needs more leading */
}

:lang(zh-hans) {
  font-family: 'Noto Sans SC', 'PingFang SC', sans-serif;
}

This CSS :lang() selector approach keeps language-specific typography rules close to the semantic language declaration, making maintenance more straightforward as international content grows.

Testing with Screen Readers

Effective screen reader testing requires actually using a screen reader, not just running automated tools. Automated tools catch structural issues but cannot assess the quality of the listening experience.

NVDA + Firefox (Windows, free): The most commonly used combination in accessibility testing. NVDA is a free, open-source screen reader. Download from nvaccess.org. Use with Firefox for best compatibility.

VoiceOver + Safari (macOS, built-in): Available on every Mac (Cmd+F5 to toggle). VoiceOver with Safari is the standard combination for macOS testing. Use VoiceOver + Chrome for a different browser perspective.

TalkBack (Android): Built into Android devices. Settings → Accessibility → TalkBack. Essential for testing mobile web accessibility.

Basic testing workflow:

1. Turn off your monitor (or close your eyes). Rely entirely on audio.
2. Navigate to a page using only the keyboard and screen reader commands.
3. Use heading navigation (H key in NVDA/JAWS) to jump between headings. Does the structure make sense? Are you finding the content you expect?
4. Navigate links list (Insert+F7 in NVDA). Are link texts descriptive out of context?
5. Navigate form fields. Are labels announced correctly?
6. Find any icon-only buttons. Are their purposes announced?

For automated testing that catches some screen-reader-relevant issues, axe-core is the standard:

# Install axe-cli
npm install -g @axe-core/cli

# Test for WCAG AA issues (includes heading structure, ARIA, lang attributes)
axe https://example.com --tags wcag2aa --reporter cli

# Test for specific screen reader rules
axe https://example.com --rules region,landmark-one-main,heading-order

Heading order specifically can be tested with the axe rule heading-order, which flags non-sequential heading levels. The browser extension versions of axe (axe DevTools) also include a visual heading map overlay — a useful tool for auditing heading hierarchy without a screen reader.

Screen reader accessibility and visual typography are not separate concerns. Every semantic HTML decision you make in service of good typography — using real headings, giving elements proper language attributes, hiding decorative icons — is simultaneously a screen reader accessibility decision. The two disciplines are, at the HTML layer, the same work.