Audit Finding: Missing Nav Landmark on Orientation-Locked Demo Page

"We thought we were compliant." Those five words appear in more ADA settlement preambles than any other phrase — and they almost always trace back to the same root cause: teams that checked some boxes but missed the structural ones.

The automated analysis of this orientation-locked demonstration page (opens in new window) surfaces exactly one accessibility issue. One. That's worth examining carefully — not because the finding is catastrophic, but because of what it reveals about how structural accessibility works, and how close a page can get to solid without quite arriving.

The Finding

The automated scan identified a single WCAG 2.1 Level AA (opens in new window) structural violation:

No <nav> landmark found.

This violates WCAG 1.3.6 Identify Purpose (opens in new window) and more directly WCAG 2.4.1 Bypass Blocks (opens in new window), which requires that users have a mechanism to skip repeated navigation content — and that navigation regions be programmatically identifiable.

The problematic pattern looks like this:

<!-- What the page likely has -->
<div class="navigation">
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</div>

A <div> with navigation links is visually indistinguishable from a proper nav element. But to assistive technology, it's invisible as a landmark. The structure exists for sighted users. It doesn't exist for screen reader users navigating by landmark.

For reference, the page passes four checks: the "View WCAG Guidelines" button has an accessible name, heading structure follows a logical H1 → H2 → H3 → H2 → H2 → H3 sequence, and both <main> and <header> landmarks are present. That's a meaningful baseline. The nav omission is the gap.

Why This Matters

Screen reader users navigate pages differently than sighted users. Rather than scanning visually, many use landmark navigation — jumping between <header>, <main>, <nav>, and <footer> regions to orient themselves and find content efficiently. NVDA, JAWS, and VoiceOver all support this pattern natively.

When <nav> is absent, two things happen:

First, users lose orientation. They can't quickly answer "where is the navigation on this page?" without reading through content linearly to find it.

Second, skip navigation breaks down. WCAG 2.4.1 (opens in new window) exists specifically so keyboard users don't have to tab through every navigation link before reaching main content. Without a programmatically identified nav region, that bypass mechanism has nothing to anchor to.

For a demonstration page about orientation locking — a criterion that directly affects users who rely on specific device orientations due to motor or mounting constraints — this gap has a certain irony. The page exists to teach accessibility. Its navigation structure undermines the lesson.

Best Practices

The fix is straightforward:

<!-- Correct pattern -->
<nav aria-label="Main navigation">
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

If a page has multiple navigation regions — site nav, breadcrumbs, in-page section links — each needs a distinct aria-label or aria-labelledby attribute so screen readers can distinguish them:

<nav aria-label="Site navigation">
  <!-- primary links -->
</nav>
<nav aria-label="Page sections">
  <!-- in-page anchor links -->
</nav>

The ARIA Authoring Practices Guide (opens in new window) documents this pattern in detail. The <nav> element is one of the HTML5 sectioning elements with implicit ARIA role — using it correctly requires no additional ARIA attributes for basic landmark exposure, though labels become essential when multiples exist on a page.

Applying This

In code review: Flag any <div> or <ul> containing navigation links that isn't wrapped in <nav>. This is a one-line check that catches a persistent pattern.

In automated testing: Most major tools — axe-core, Lighthouse, WAVE — will surface missing nav landmarks. If your CI pipeline runs axe-core, this finding would appear under the region rule. If it didn't surface in your pipeline, that's worth investigating — it may indicate your test coverage isn't reaching navigation components.

Quick win: This is a single-element change. Swapping <div class="nav"> for <nav aria-label="Main navigation"> takes minutes. It's the definition of a "chop list" item — low skill required, immediate landmark accessibility restored.

Longer-term: Audit all page templates for landmark completeness. A page that has <main> and <header> but no <nav> suggests the landmark audit was partial. Check for <footer>, <aside> (for complementary content), and <section> elements with appropriate labels.

Our research on automated versus manual testing methodology is relevant here: automated tools caught this finding cleanly because missing landmarks are binary — either the element exists or it doesn't. But automated tools couldn't tell you whether the navigation content serves users well, whether the link text is descriptive, or whether the navigation order makes cognitive sense. This finding is the floor, not the ceiling.

CORS Perspective

Through the CORS framework, this finding maps cleanly across all four pillars. Community: screen reader and keyboard users are the directly affected population — people who depend on landmark navigation for basic page orientation. Operational: the fix requires no specialized expertise, just a one-element HTML change and a template update; this belongs on every team's chop list. Risk: missing navigation landmarks are detectable by automated tools used in ADA litigation, making this a straightforward compliance exposure — WCAG 2.4.1 (opens in new window) is a Level A criterion, the baseline tier. Strategic: the broader lesson for development teams is that passing some landmark checks doesn't mean landmark structure is complete — a page with <main> and <header> but no <nav> has partial structure, not full structure, and the gap between those two states is where users get lost.

The page being analyzed exists to demonstrate WCAG violations. Finding a structural gap in its own navigation is a useful reminder that accessibility requires systematic review, not assumption. As our analysis of compliance framework challenges shows, organizations often achieve partial compliance and mistake it for full compliance. One missing landmark. One real barrier. Fix it, then audit the template it came from.