All Caps Text Audit: One Issue, A Bigger Lesson

Automated accessibility testing catches what it can measure. That boundary matters more than most teams realize.

The automated analysis of the Text All Caps test page (opens in new window) returned one violation and four passing checks. On the surface, that looks like a nearly clean page. But the page's own stated purpose — demonstrating the accessibility problems caused by all-caps text — exposes a gap that no automated scanner can close. The structural issue is real and fixable. The cognitive and readability harm from all-caps text is equally real, and largely invisible to tools.

Here's what the analysis actually found, and what it couldn't.

THE FINDING

The automated scan identified one WCAG 2.1 violation: the absence of a <nav> landmark element.

This violates WCAG 1.3.1 Info and Relationships (opens in new window) (Level A), which requires that information conveyed through structure and layout be available programmatically — not just visually. Navigation regions are a core structural element. When they exist visually but lack semantic markup, assistive technologies have no way to expose them.

The page also passed four checks: the primary button has an accessible name, the heading hierarchy is valid (H1 → H2 → H3 → H2 → H2 → H3), a <main> landmark is present, and a <header> landmark is present. That's a reasonable structural foundation.

The problematic pattern looks like this:

<!-- What the page likely has -->
<div class="navigation">
  <a href="/">Home</a>
  <a href="/guidelines">Guidelines</a>
</div>

The fix is straightforward:

<!-- Correct semantic pattern -->
<nav aria-label="Main navigation">
  <a href="/">Home</a>
  <a href="/guidelines">Guidelines</a>
</nav>

If the page has multiple navigation regions, each needs a distinct aria-label to distinguish them — for example, aria-label="Primary" and aria-label="Footer".

WHY THIS MATTERS

Screen reader users navigate by landmarks. Tools like NVDA, JAWS, and VoiceOver allow users to pull up a list of all landmark regions on a page and jump directly to them. A <div> with a navigation-like class doesn't appear in that list. The user either has to read through the entire page linearly or guess where navigation might be.

For a simple test page, that's a minor inconvenience. Scale this pattern to a university portal or transit system website — environments where Title II compliance requirements apply — and the cumulative burden becomes significant. Users with motor impairments relying on switch access, or blind users moving through complex interfaces, lose the ability to orient themselves efficiently.

The <nav> element costs nothing to implement. Its absence is a choice, usually an uninformed one.

THE DEEPER PROBLEM: WHAT AUTOMATION MISSED

This page is specifically designed to demonstrate all-caps text accessibility violations. The automated scan found zero issues with the all-caps text itself. That's not a failure of this particular tool — it's a structural limitation of automated testing.

WCAG 1.4.8 Visual Presentation (opens in new window) (Level AAA) addresses text presentation, but the more practically relevant concern sits at WCAG 1.4.4 Resize Text (opens in new window) and the broader readability principles underlying WCAG 3.1 Readable (opens in new window). All-caps text creates measurable cognitive load: it removes the ascender and descender variation that helps readers distinguish letterforms quickly. For users with dyslexia, cognitive disabilities, or low literacy, sustained all-caps passages can make text functionally unreadable even when it technically passes contrast checks.

No automated scanner flags this. It requires human judgment.

This gap is well-documented. Our research paper Beyond Detection: Why Context Separates Automated Testing from Manual Audits establishes that automated tools capture at most 37% of real accessibility barriers. A page like this one — structurally clean, typographically harmful — sits squarely in the 63% that automation misses.

BEST PRACTICES

For the landmark violation, the fix is a one-line change. Add <nav> with a descriptive label:

<nav aria-label="Site navigation">
  <!-- navigation links -->
</nav>

For all-caps text, the correct approach is CSS-based rendering rather than uppercase source text. This preserves the underlying text for screen readers while controlling visual presentation:

/* Use CSS for visual styling, not HTML source text */
.section-heading {
  text-transform: uppercase;
}

<!-- Screen readers read this correctly as "Section Title" -->
<h2 class="section-heading">Section Title</h2>
<!-- Avoid this — screen readers may spell out or read awkwardly -->
<h2>SECTION TITLE</h2>

The CSS approach matters because some screen readers handle all-caps source text differently — some read letter by letter, some read normally, behavior varies by reader and configuration. Keeping source text in standard case eliminates that variability entirely.

APPLYING THIS

For development teams, the landmark fix belongs on the "chop list" — low effort, immediate impact, zero ambiguity. Add it to your linting rules. Tools like axe-core (opens in new window) and Lighthouse (opens in new window) will catch missing landmarks in CI pipelines if configured correctly.

The all-caps readability issue is a design system conversation, not a sprint ticket. It requires establishing a typographic policy: all-caps is acceptable for short labels (button text, abbreviations, navigation items under 3-4 words) and should be avoided for body text, headings, or any passage requiring sustained reading. That policy needs to live in your design tokens and component library, not in individual developer decisions.

Teams relying exclusively on automated scanning to certify accessibility should review The Methodology Paradox: Why Automated Testing and Manual Audits Both Fail. The hybrid approach — automated scanning for structural issues, human review for cognitive and contextual barriers — is the only methodology that catches both categories reliably.

CORS PERSPECTIVE

From a balanced CORS lens, this audit illustrates an operational capacity problem that has strategic consequences. Organizations that instrument their pipelines for automated testing and declare compliance have addressed perhaps a third of actual barriers — the structurally detectable ones. The community impact falls disproportionately on users with cognitive disabilities and dyslexia, who encounter the typographic harms that automation never flags. The risk exposure is real: as our research on compliance frameworks documents, organizations often discover these gaps only when a complaint or litigation forces a manual audit. The strategic fix is building human review capacity alongside automated tooling — not as a luxury, but as a baseline requirement for honest compliance claims.