Landmark Failures on a Multilingual Page: An Audit Finding

The test page at wcagrepo.netlify.app/13-internationalisation (opens in new window) is a reasonable approximation of something real: a corporate partner directory spanning four countries, four languages, and four regulatory contexts. French RGAA. German BITV 2.0. Japanese JIS X 8341-3. Brazilian LBI. The page's own content is literally about accessibility compliance across international standards.

And yet the automated analysis identified three structural violations that would make this page nearly unusable for screen reader users — all of them fixable in under an hour.

Once again, we're seeing the gap between talking about accessibility and building it.

THE FINDINGS

The static analysis flagged three violations against WCAG 2.1 Success Criterion 1.3.6 Identify Purpose (opens in new window) and, more directly, WCAG 1.3.1 Info and Relationships (opens in new window) — the criterion requiring that structure conveyed visually also be programmatically determinable.

The three missing landmarks:

1. No <main> landmark — the primary content region is not identified
2. No <nav> landmark — navigation links have no semantic role
3. No <header> / banner landmark — the page header carries no programmatic identity

These map directly to WCAG 2.4.1 Bypass Blocks (opens in new window) (Level A), which requires a mechanism to skip repeated content and reach the main content area. Without a <main> landmark, that mechanism doesn't exist.

The one passing check: heading structure (H1 → H2 → H3) is correct. That's not nothing — a coherent heading outline gives screen reader users something to work with. But it doesn't compensate for absent landmarks.

What the broken markup looks like

The page likely renders something structurally like this:

<!-- Missing landmark structure -->
<div class="header">Global Partners</div>
<div class="nav">...</div>
<div class="content">
  <h1>Global Partners</h1>
  <!-- partner cards -->
</div>

Visually, this looks fine. To a screen reader, it's a flat document with no navigable regions.

WHY THIS MATTERS

Screen reader users navigate pages the way sighted users scan them — by jumping between structural elements. NVDA, JAWS, and VoiceOver all provide landmark navigation shortcuts (typically the D key in NVDA/JAWS, the rotor in VoiceOver). When landmarks are absent, those shortcuts return nothing.

On a page this long — four international partner entries, each with quotes in a foreign language, addresses, and contact details — the absence of a <main> landmark forces a screen reader user to tab through every element from the top of the page to reach the actual content. Every. Single. Time. There's no skip mechanism. No way to jump directly to the partner listings.

The missing <nav> landmark compounds this. Navigation menus without semantic role can't be identified as navigation, can't be skipped, and can't be targeted directly. Users either wade through them or miss them entirely.

For switch users and keyboard-only navigators, the experience is similar: no structural anchors means linear traversal is the only option.

The multilingual content adds another layer. Assistive technologies need language signals to switch text-to-speech voices correctly — a French quote read by an English TTS engine is often incomprehensible. The WCAG 3.1.2 Language of Parts (opens in new window) criterion addresses this directly, and while the static analysis didn't flag it explicitly, a page with French, German, Japanese, and Portuguese content blocks is a high-probability candidate for lang attribute failures on those inline sections. Worth a manual check.

BEST PRACTICES

The fix for landmark violations is straightforward semantic HTML. Replace generic <div> containers with their appropriate landmark elements:

<!-- Correct landmark structure -->
<header>
  <a href="#main-content" class="skip-link">Skip to main content</a>
  <!-- logo, site name -->
</header>

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

<main id="main-content">
  <h1>Global Partners</h1>
  <!-- partner cards -->
</main>

<footer>
  <!-- footer content -->
</footer>

For the multilingual content blocks, each language section should carry an explicit lang attribute:

<!-- French partner card -->
<article lang="fr">
  <h2>Acme France SAS</h2>
  <blockquote>
    <p>« Acme nous a permis de réduire notre temps d'audit d'accessibilité de 60 %. »</p>
    <cite>— Marie-Claire Dupont, Directrice des Opérations</cite>
  </blockquote>
</article>

<!-- Japanese partner card -->
<article lang="ja">
  <h2>Acme Japan 株式会社</h2>
  <blockquote>
    <p>「Acmeのツールにより、JIS X 8341-3に準拠したウェブサイトを短期間で実現できました。」</p>
    <cite>— 田中 健太, デジタル推進部長</cite>
  </blockquote>
</article>

The <article> element is appropriate here — each partner entry is self-contained, independently meaningful content. The ARIA Authoring Practices Guide (opens in new window) confirms that <article> creates an implicit article landmark role, which further aids navigation in longer documents.

APPLYING THIS

Quick wins (under 1 hour): Landmark additions are a template-level fix. If this page is generated from a CMS or component library, one change propagates everywhere. Audit your base template first — not individual pages.

In code review: Add a landmark checklist to your PR template. Every page template should have <header>, <nav>, <main>, and <footer> before it ships. Automated tools like axe-core (opens in new window) catch missing <main> landmarks reliably — this is exactly the kind of issue automated testing should be catching before it reaches production.

The lang attribute gap: Automated tools often miss missing lang attributes on inline foreign-language content. This requires manual review. Our research paper Beyond Detection: Why Context Separates Automated Testing from Manual Audits documents why — automated tools top out at roughly 37% detection against comprehensive manual audits. Language of parts failures sit firmly in that undetected 63%.

For multilingual sites specifically: Build language tagging into your content model, not as an afterthought. If your CMS stores content by locale, it should also output the correct lang attribute on the rendered HTML fragment. This is an architectural decision, not a copy-editing task.

CORS PERSPECTIVE

The strategic irony here is hard to miss. This page's content explicitly references RGAA, BITV 2.0, JIS X 8341-3, and Brazil's Lei Brasileira de Inclusão — four distinct national accessibility frameworks that organizations navigating multi-standard compliance must reconcile. The page markets accessibility expertise to international partners while failing WCAG Level A requirements that all four of those frameworks inherit. From a strategic alignment standpoint, that's a credibility problem, not just a technical one. The operational fix takes an hour. The reputational cost of a disabled user finding it takes considerably longer to recover from.