Most writers think of text case as a visual choice. For users of screen readers and other assistive technology, capitalization choices have audible consequences. The same word can be pronounced as a word, spelled out letter by letter, or pronounced in pieces depending on how it's capitalized. Get the case right and your content is more accessible; get it wrong and you create friction that sighted readers never see.

Here's what every writer should know about how screen readers handle case.

How screen readers parse capitalization

Screen readers (NVDA, JAWS, VoiceOver, TalkBack, Narrator) use heuristics to decide whether a string of letters is a word or an acronym. The dominant heuristic: all-uppercase letters are treated as acronyms and spelled out letter by letter.

This produces predictable behavior for common acronyms:

  • NASA → "N-A-S-A" (spelled out)
  • FBI → "F-B-I" (spelled out)
  • USB → "U-S-B" (spelled out)
  • NATO → "N-A-T-O" (spelled out)

Mixed-case text is treated as words:

  • Hello → "hello"
  • iPhone → "iPhone" or "i-Phone" depending on the screen reader
  • NASA scientist → "N-A-S-A scientist"

The problem with all-caps body text

If you set body text in all uppercase for visual emphasis, screen readers may interpret each word as an acronym and spell it out:

"IMPORTANT NOTICE: READ CAREFULLY" might be read as "I-M-P-O-R-T-A-N-T N-O-T-I-C-E: R-E-A-D C-A-R-E-F-U-L-L-Y."

This makes the content nearly unusable for screen reader users. The visual emphasis you intended produces auditory nonsense.

Modern screen readers have improved at detecting "this isn't really an acronym, it's just styled in caps," but the detection isn't perfect. Some screen readers, in some settings, still spell out longer all-caps strings. The safe practice is to never use all-caps for accessibility-critical content.

What to do instead

Use CSS to display text in uppercase visually while keeping the underlying HTML in mixed case:

<!-- Bad: hurts screen readers -->
<h1>IMPORTANT NOTICE</h1>

<!-- Good: visually uppercase but accessible -->
<h1 class="upper">Important Notice</h1>

<style>
.upper { text-transform: uppercase; }
</style>

The CSS text-transform: uppercase renders the text in capitals visually while leaving the underlying letters mixed-case. Screen readers read the underlying HTML, so they pronounce the text as words.

This is one of the more common accessibility wins: it costs nothing to implement and provides a clean fallback for assistive technology.

Acronyms and abbreviations

For real acronyms (NASA, FBI, NATO), the spelled-out screen reader behavior is correct — that's how sighted readers usually pronounce them. But some acronyms are pronounced as words ("NASA" as "nass-a", not "N-A-S-A"). Some are abbreviations of longer phrases that should be expanded.

HTML provides the <abbr> element with a title attribute for these cases:

<abbr title="National Aeronautics and Space Administration">NASA</abbr>
<abbr title="Hypertext Markup Language">HTML</abbr>
<abbr title="application programming interface">API</abbr>

Screen reader behavior with <abbr> varies:

  • JAWS reads the title attribute on first encounter, then uses the abbreviation
  • NVDA announces both the abbreviation and its expansion based on user settings
  • VoiceOver can be configured to read titles for abbreviations

The behavior isn't universal, but the markup at least gives screen readers the information they need to handle the abbreviation appropriately.

camelCase and PascalCase identifiers

For technical content with code identifiers (variable names, class names, function names), screen reader behavior depends on the screen reader and its settings:

  • userName → "user name" or "userName" (with pause) depending on settings
  • HTMLParser → "H-T-M-L parser" or "HTML parser" depending on settings
  • parseURL → "parse URL" or "parse U-R-L" depending

Many screen readers have a "speak word breaks" or "expand symbols" mode that splits camelCase identifiers at the case transition. With this mode enabled, userName is read as "user name" — usable.

For technical documentation, this is fine. Developers using screen readers typically have these settings configured. For non-technical content, avoid embedding camelCase in regular prose without context.

Title case versus sentence case

Title case and sentence case sound the same to screen readers in most cases. The word "Hello" is read the same whether the H is capitalized for sentence case or for title case.

The exceptions:

  • Some screen readers have a "capitalization" announcement mode that says "cap" before capitalized letters. With this mode on, "Hello World" would be read as "cap H, e-l-l-o, cap W, o-r-l-d." This is rare and usually off by default.
  • Some screen readers change pitch slightly on capitalized letters. This is subtle but audible.

For most accessibility purposes, title case and sentence case are equivalent. The choice between them is driven by other factors (style, brand voice, audience expectation) rather than accessibility.

Lowercase brand names

Brand names with deliberate lowercase first letters (iPhone, eBay, jQuery) are read by screen readers as words. The lowercase letter doesn't change the pronunciation. iPhone is read as "iPhone"; eBay is read as "eBay."

This is a case where the brand's own marketing materials get the screen reader experience for free. The lowercase first letter signals "tech brand" to sighted readers; for screen reader users, it just sounds like the brand name.

Underscore_separated and hyphen-separated identifiers

Most screen readers, by default, read underscores as "underscore" and hyphens as a pause:

  • user_name → "user underscore name"
  • user-name → "user, name" (pause)
  • user.name → "user dot name"
  • user/name → "user slash name"

For code or technical content, this is usually correct — developers want to hear the punctuation. For URLs and slugs, the hyphen behavior produces readable output.

Users can typically configure their screen readers to skip or pronounce punctuation differently based on the context (verbose mode reads everything; reading mode skips most punctuation). Don't optimize for a specific punctuation-reading setting — write content that works in any mode.

The role of semantic HTML

Beyond case-specific accessibility, the most impactful thing you can do for screen reader users is use semantic HTML correctly:

  • Use heading levels (h1-h6) for hierarchy. Screen readers let users navigate by heading, so accurate hierarchy is essential.
  • Use <strong> for emphasis, not all-caps or bold-only styling. Screen readers can indicate emphasis through prosody.
  • Use <em> for stress emphasis, not italics. Same reason.
  • Use <abbr> with title for abbreviations. As discussed above.
  • Use lists (<ul>, <ol>) for actual lists. Screen readers announce the list and item count.

Case choices interact with these structures. A heading in all-caps reads worse than a heading in title case, but the heading itself (correct h2, in the right place) matters more than the case it's set in.

Internationalization and screen readers

Different languages have different case behaviors that interact with screen reader pronunciation:

  • German: capitalizes all nouns. Screen readers handle this correctly without special configuration.
  • Romance languages: don't typically use title case for headings. Don't apply English-style title case to translated content.
  • Languages without case: Chinese, Japanese, Korean, Arabic, Hebrew don't have case. The conversation doesn't apply.
  • Mixed-language content: be careful about applying English title-case rules to inline foreign words. Screen readers may not switch languages mid-sentence, leading to mispronunciation.

Testing your content with screen readers

The best way to understand how your content reads with a screen reader is to use one. Several options:

  • NVDA (Windows, free) — most popular Windows screen reader for developers
  • JAWS (Windows, paid) — industry standard for enterprise use
  • VoiceOver (macOS/iOS, built-in) — activate with Cmd+F5
  • TalkBack (Android, built-in)
  • Narrator (Windows, built-in)

Spend 30 minutes navigating your own site with VoiceOver or NVDA. You'll discover issues you couldn't predict from reading the HTML — text that gets read wrong, headings that aren't where you'd expect, all-caps text that gets spelled out letter by letter.

Common case-related accessibility mistakes

Setting body text in ALL CAPS. Even if visually emphasized, this hurts screen readers and slows down sighted readers too.

Using ALL CAPS for navigation labels. Common in some design systems. Use CSS text-transform: uppercase instead.

Hiding text from screen readers using visual case tricks. If text is visible, it should be readable by screen readers.

Spelling out acronyms unnecessarily. "FBI" doesn't need to be spelled "F-B-I" in your HTML — the screen reader handles that. Just write "FBI."

Using camelCase or snake_case in user-facing text. "userName" is fine in code; "user_name" is fine in code. In UI labels, write "Username" or "User name."

Putting acronyms in titles without context. A page titled "AWS RDS PostgreSQL Setup" hits a screen reader with three acronyms in a row, each spelled out. Consider "Setting up PostgreSQL on Amazon RDS" as a more accessible alternative.

The practical takeaway

Accessibility for case-related content boils down to:

  1. Never use ALL CAPS in HTML for body content. Use CSS text-transform if you want the visual effect.
  2. Mark up abbreviations with <abbr> and title attributes.
  3. Don't embed unfamiliar camelCase or snake_case identifiers in user-facing prose without context.
  4. Test with at least one screen reader before publishing major content.
  5. Trust the user's screen reader settings — don't try to game pronunciation through ad-hoc spelling.

The goal is content that works as well audibly as it does visually. Most case-related accessibility wins are small, low-cost, and obvious once you've tried using a screen reader yourself. The investment in learning what your content sounds like is small; the impact on users with assistive technology is significant.

If you need to convert content between cases — for instance, to take an all-caps marketing email and reformat it as accessible mixed-case content — our case converter can rapidly switch between formats. The bulk converter handles whole files at once.