The Accessible Version Nobody Can Find

There's a conforming version of the page. It exists. Someone built it. And the user who needs it has no idea it's there.

This is the failure WCAG 2.2 Failure F19 (opens in new window) documents — not a missing alternative, but a hidden one. Organizations that build accessible versions of inaccessible content and then bury them have done half the work and none of the good. The W3C is direct about why this fails: "the user cannot find the conforming version." Existence without discoverability is not access.

The Failure

F19 applies to a specific scenario: a site offers both a nonconforming primary page and a separate, WCAG-conforming alternative. The failure occurs when there's no clear path from the nonconforming page to the conforming one.

The official W3C document (opens in new window) describes three distinct patterns, each worth examining:

Pattern 1 — No indication at all. A user lands on a nonconforming page through a link or search result. There's no mention that an accessible version exists. No link. No notice. Nothing.

Pattern 2 — The homepage redirect. The nonconforming page acknowledges a conforming version exists and links to the home page. But the user must then search the site to find it. W3C is explicit: this does not meet the requirement. Sending someone to a homepage is not a path to the content they need.

Pattern 3 — Partial coverage. The user can navigate most of the site without issue. But when they hit a page they cannot access, there's no conforming alternative offered at that specific point of failure.

All three patterns share the same structural problem: the organization treated accessibility as a content problem (build an alternative) rather than a navigation problem (ensure people can reach it).

<!-- FAILURE PATTERN: Nonconforming page with no path forward -->
<main>
  <h1>Annual Report 2024</h1>
  <!-- Complex inaccessible data visualization -->
  <div id="chart-container" aria-hidden="true">...</div>
  <!-- No link to accessible version anywhere on page -->
</main>
<!-- ALSO FAILS: Vague reference without a direct link -->
<footer>
  <p>An accessible version of this site is available. 
  Visit our <a href="/">home page</a> for more information.</p>
</footer>

This failure doesn't map to a specific numbered WCAG success criterion — it maps to WCAG 2.2 Conformance Requirement 1 (opens in new window), which governs when and how conformance claims are valid. Conformance Requirement 1 permits nonconforming pages only when a conforming alternative exists and the nonconforming page provides a direct way to reach it.

Why This Matters

The gap between "we have an accessible version" and "disabled users can find it" is where a lot of well-intentioned accessibility work disappears.

Consider a screen reader user who arrives at a page through a search engine or shared link. They're dropped directly into a nonconforming experience. If there's no in-page notice — no link, no landmark, no announcement — they have two options: struggle through inaccessible content, or leave. Neither option is access.

For users with cognitive disabilities, the burden compounds. Even if a vague notice exists somewhere on the page, locating it, parsing it, and navigating to a home page to then search for the correct content is a multi-step task that shouldn't exist. The conforming version should be one step away, not three.

Keyboard-only users face a similar problem. If the nonconforming page has broken focus management or inaccessible interactive elements, they may not be able to reach a buried footer link even if one exists.

The pattern also has a temporal dimension. Users who encounter the site repeatedly learn where barriers are. First-time users — often the ones with the most urgent need — have no such map.

The Fix

The corrected pattern is straightforward: place a direct, prominent link to the conforming version on the nonconforming page itself, early enough in the content that users encounter it before hitting barriers.

<!-- CORRECT PATTERN: Direct link at top of nonconforming page -->
<main>
  <div class="accessibility-notice">
    <p>This page contains content that may not be fully accessible. 
    <a href="/annual-report-2024-accessible">View the accessible version 
    of the 2024 Annual Report</a>.</p>
  </div>
  
  <h1>Annual Report 2024</h1>
  <!-- Complex visualization -->
  <div id="chart-container" aria-hidden="true">...</div>
</main>

The link must be:

• Specific — it goes directly to the conforming version of this content, not a homepage or search page
• Early — positioned before the inaccessible content, not buried in a footer
• Descriptive — the anchor text identifies what the user will find, not just "click here" or "accessible version"
• Functional — reachable by keyboard, announced by screen readers, visible to sighted users

For sites with many nonconforming pages, this means implementing the notice pattern systematically — not page by page as complaints arrive, but as a template-level decision. If your CMS generates nonconforming content, the notice should be part of the template.

Applying This

F19 sits in a detection blind spot. Automated testing tools scan for what's present — missing alt text, invalid ARIA, poor contrast. They don't reliably flag what's absent: the notice that should be there but isn't. Our research on automated testing limitations found that automated tools catch at most 37% of real accessibility failures. F19-type omissions are exactly the kind of issue that falls into the other 63%.

For code review, add a specific checkpoint: If this page has known accessibility failures, is there a direct link to a conforming alternative? Make it part of your definition of done for any page that ships with known nonconformance.

For QA, test the user journey from external entry points — search results, shared links, email campaigns. Don't just test from your navigation. Users arrive where they arrive, and the conforming path needs to be visible from wherever that is.

For content teams managing large site migrations, this failure often emerges during phased rollouts: the new accessible pages exist, but the old pages haven't been updated with links to them yet. Build the redirect or notice into the publishing workflow, not as a cleanup task afterward.

Organizations navigating multiple compliance frameworks — Section 508, EN 301 549, state-level requirements alongside WCAG — often deprioritize conformance-level requirements in favor of success-criterion-level fixes. Our analysis in The Compliance Framework Paradox documents how this fragmentation leads to exactly these kinds of gaps: the structural requirements get lost while teams focus on measurable checkpoints.

CORS Perspective

From a community impact lens, F19 is a visibility failure with a familiar shape. Disabled users are frequently told that accommodations exist — accessible entrances, captioned videos, alternative formats — without being told where or how to access them. The digital version of this pattern is a conforming web page that no one can find. The Southeast ADA Center (opens in new window) consistently documents this gap between accommodation availability and accommodation discoverability as one of the most persistent barriers in both physical and digital spaces. Operationally, the fix is low-cost once teams understand that the conforming alternative is only half the solution — the navigation path is the other half, and it belongs in the template, not the to-do list. The risk calculus is clear: a conformance claim built on Conformance Requirement 1 collapses the moment a user can demonstrate they couldn't find the alternative, which makes F19 both a legal exposure and a credibility problem. Strategically, organizations that treat this as a one-time template fix rather than a recurring audit item are the ones that get it right.