Beyond the Fix: Why Landmark Violations Keep Recurring

Fixing three missing landmarks takes an afternoon. Preventing them from reappearing takes something harder: organizational systems that center disabled users before code ships.

Jamie's analysis of the Acme Learning Hub's missing landmarks is technically precise. Add <main>, <nav>, and <header>. Map them to WCAG 1.3.1 and 2.4.1. Done. The code fix is genuinely that simple. But in fifteen years of covering digital accessibility, I've watched organizations patch the same landmark violations on the same pages across multiple audit cycles. The technical solution isn't the hard part. The organizational conditions that allow semantic HTML to get stripped out — or never added — in the first place are.

This piece isn't a rebuttal to the technical findings. Those findings are correct. It's an argument that the framing of "here's what's broken and how to fix it" skips the more consequential question: why does this keep happening, and whose voice is missing from the process that would prevent it?

Why Landmark Violations Recur Across Audit Cycles

Landmark violations are among the most commonly cited issues in accessibility audits, and they are also among the most commonly re-cited. The WebAIM Million report (opens in new window), which analyzes the top one million home pages annually, consistently finds that structural and semantic failures dominate the accessibility error landscape. In the 2024 report, 95.9% of home pages had detectable WCAG failures — and missing or improper landmark structure appears repeatedly across audit categories.

These aren't new problems. ARIA landmark roles have been part of the WAI-ARIA specification (opens in new window) since 2008. Native HTML5 sectioning elements — <main>, <nav>, <header>, <footer> — have had broad browser support for over a decade. The Section508.gov guidance on page structure (opens in new window) has been publicly available for years. Organizations are not failing to add landmarks because the technical knowledge doesn't exist. They're failing because the systems that would catch these omissions before deployment aren't in place — and because the people most affected by their absence are rarely in the room when design and development decisions get made.

What Automated Testing Catches — and What It Doesn't

The analysis Jamie documented used static automated analysis, which is exactly the right tool for detecting missing structural elements. Automated tools are reliable for this category of violation. But automated testing has a well-documented ceiling.

According to research published by the Deque Systems accessibility team (opens in new window), automated tools can detect approximately 30–40% of WCAG issues. The remaining 60–70% require human judgment — and the most meaningful human judgment comes from disabled users operating real assistive technologies in real use contexts. A screen reader user navigating the Acme Learning Hub doesn't just notice that landmarks are missing. They notice which content they're stranded in front of, how long they spend trying to orient themselves, and whether they give up before reaching the material they came for. That experiential data doesn't appear in an automated report.

This is the gap that community input addresses — not as a supplementary nice-to-have, but as the primary source of information about whether a product is actually usable. Our editorial approach at this publication treats disabled user experience as the authoritative measure of accessibility, not WCAG conformance scores. Those two things frequently correlate, but they are not the same thing.

The Community Input Deficit

The DOJ's guidance on web accessibility under the ADA (opens in new window) frames digital access as a civil rights obligation. That framing matters because civil rights frameworks center the people whose rights are at stake — not the technical standards that operationalize those rights. When organizations treat accessibility as a compliance checklist, they optimize for passing audits. When they treat it as a community obligation, they build feedback loops with disabled users that catch problems automated tools miss and prevent regressions that automated tools can't anticipate.

Practically, this means several things most organizations aren't doing: including screen reader users in usability testing before launch, not after an audit flags violations; maintaining ongoing relationships with disability community organizations rather than one-time consultations; and creating accessible feedback mechanisms so that users who encounter barriers can report them without navigating additional obstacles. The Great Lakes ADA Center's resources on inclusive design processes (opens in new window) offer frameworks for this kind of sustained community engagement that go well beyond technical remediation.

None of this is visible in the Acme Learning Hub's missing landmarks — but all of it is implied by them. When <div class="nav"> ships instead of <nav>, it's a signal that no screen reader user tested that page before it went live. It's a signal that accessibility review, if it happened at all, happened after the fact. It's a signal that the people most affected by the decision had no input into it.

Structural Prevention Over Reactive Patching

Building on the technical framework Jamie established, the question for organizations isn't just "how do we fix these three violations" but "what would have to be true for these violations to never ship."

The answer involves several intersecting changes. Development teams need accessibility integrated into their definition of done — not as a separate audit phase but as a build-time requirement, using tools like axe-core (opens in new window) in CI/CD pipelines to catch structural violations before code merges. Design systems need semantic HTML baked into their component libraries so that developers reaching for a navigation component get <nav> by default, not a styled <div>. And organizations need to establish direct relationships with disabled users — through paid user research, community advisory panels, or partnerships with disability-led organizations — so that the experiential reality of using assistive technology on their products is part of the product development conversation from the start.

The Pacific ADA Center's technical assistance resources (opens in new window) and the broader network of ADA Centers offer consultation specifically for organizations trying to build these kinds of systemic processes, not just remediate individual violations.

Landmarks are structural. So is the organizational failure that produces their absence. Fixing the HTML is necessary. Building the systems and community relationships that prevent the regression is the work that actually changes outcomes for disabled users — and it's the work that most audit reports, however technically accurate, don't address.