What Acme Corp's Accessibility Report Doesn't Report On

The page that tracks accessibility violations across four products has accessibility violations of its own. The automated analysis of Acme Corp's Q1 2026 Accessibility Report (opens in new window) identified seven distinct barriers — none of which appear in the violation summary the page displays. That gap is worth sitting with for a moment.

This isn't a gotcha. It's a pattern. Accessibility reporting infrastructure is frequently built by the same teams, under the same constraints, using the same assumptions as the products being reported on. The report becomes a mirror of the organization's accessibility maturity — not just a measurement of it.

The Finding

The analysis found seven violations against WCAG 2.1 (opens in new window) on a page that also passes seven checks. That near-even split tells a story: the form elements at the bottom of the page — first name, last name, email, role, notes, the save button — are all properly labeled. Someone built that form carefully. The structural scaffolding around it was not given the same attention.

Here's what the automated analysis identified:

1. No <main> landmark — the page lacks a primary content region
2. No <nav> landmark — navigation is unmarked
3. No <header> / banner landmark — the page header is structurally invisible
4. Table 1: missing <caption> — screen readers cannot identify the table's purpose
5. Table 1: no <th> elements — header cells are indistinguishable from data cells
6. Table 2: missing <caption> — same problem, second table
7. Table 2: <th> elements missing scope attribute — header relationships are ambiguous

Issues 1–3 map to WCAG 2.4.1 Bypass Blocks (opens in new window) (Level A) and WCAG 1.3.1 Info and Relationships (opens in new window) (Level A). Issues 4–7 are WCAG 1.3.1 (opens in new window) violations. All are Level A — the baseline.

Why This Matters

Missing landmarks mean a screen reader user arriving at this page has no structural map. There's no way to jump to the main content, skip repetitive navigation, or orient within the page hierarchy. Every visit requires navigating from the top. For a report page that likely gets opened repeatedly by the same stakeholders, that friction compounds.

The ARIA landmark model exists precisely to solve this. Without <main>, <nav>, and <header>, assistive technologies treat the entire page as an undifferentiated block of content.

The table violations are the more consequential findings. This page contains two data tables — the violation summary by product and the WCAG criteria coverage table. These tables are the entire point of the page. They communicate which products are conformant, which criteria are failing, and whether things are improving.

A screen reader user navigating Table 1 without <th> elements hears data cells with no indication of what column or row they belong to. The numbers — 4, 1, 17, 18, 23, 12 — become meaningless without their headers. The table that reports on accessibility barriers is itself a barrier.

Table 2 has <th> elements but no scope attributes. In a complex table with both row and column headers — criterion names running down, months running across — the scope attribute tells the browser which axis each header governs. Without it, the relationship between a header cell and its data cells is ambiguous. Screen readers may announce incorrect associations.

Best Practices

Landmark Structure

The corrected page structure should include explicit landmark regions:

<header role="banner">
  <h1>Q1 2026 Accessibility Report</h1>
</header>

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

<main id="main-content">
  <!-- primary report content -->
</main>

Note that <header>, <nav>, and <main> are HTML5 semantic elements that carry implicit ARIA roles. Using the native elements is preferred over adding role attributes to generic <div> elements.

Table 1: Violation Summary

The product summary table needs a caption and proper header cells:

<table>
  <caption>Violation summary by product — Q1 2026</caption>
  <thead>
    <tr>
      <th scope="col">Product</th>
      <th scope="col">Barriers</th>
      <th scope="col">Degraded</th>
      <th scope="col">Advisory</th>
      <th scope="col">WCAG Status</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Acme Dashboard</td>
      <td>4</td>
      <td>1</td>
      <td>17</td>
      <td>Partial</td>
    </tr>
    <!-- additional rows -->
  </tbody>
</table>

Table 2: WCAG Criteria Coverage

The criteria coverage table has headers but needs scope to define their relationships:

<table>
  <caption>WCAG criteria coverage — Acme Shop, Q1 2026</caption>
  <thead>
    <tr>
      <th scope="col">Criterion</th>
      <th scope="col">Level</th>
      <th scope="col">January</th>
      <th scope="col">February</th>
      <th scope="col">Trend</th>
      <th scope="col">Tags</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">1.1.1 Non-text content</th>
      <td>A</td>
      <td>Fail</td>
      <td>Partial</td>
      <td>↑ Improving</td>
      <td>image-alt, svg</td>
    </tr>
    <!-- additional rows -->
  </tbody>
</table>

The WCAG Authoring Practices for tables (opens in new window) and the HTML specification for table headers (opens in new window) both make the scope requirement explicit for tables with headers in multiple directions.

Applying This

For development teams, these fixes fall into two categories.

Quick wins (landmarks): Adding <main>, <nav>, and <header> to an existing page is a structural change that typically takes under an hour. It requires no design changes and no stakeholder approval. Automated tools like axe-core (opens in new window) will catch missing landmarks reliably — this is one area where automated testing performs well. Add landmark checks to your CI pipeline and they won't regress.

Table fixes require more care. The <caption> and <th scope> additions are straightforward in static HTML. In a dynamically generated report — which this appears to be, given the live issue tracker and embedded benchmarking data — table structure is often controlled by a component library or a charting/table library. The fix may require modifying a shared component rather than a single template. That's worth scoping before estimating.

One question worth raising in code review: if a table's caption would be redundant with a visible heading immediately above it, use <caption class="visually-hidden"> to provide the accessible name without changing the visual design. Screen reader users need the caption; sighted users may not.

As our research into automated testing methodology documents, automated tools catch landmark and table structure issues with reasonable reliability — but they cannot evaluate whether the content of those tables is meaningful, whether the trend arrows are communicated accessibly to screen reader users, or whether the embedded external benchmarking iframe has its own accessibility properties. The seven issues found here are a floor, not a ceiling.

The Broader Question

What does it mean for an organization's accessibility program when the report that measures accessibility is not itself accessible?

There's no clean answer. It might mean the reporting infrastructure was built quickly, without the same scrutiny applied to customer-facing products. It might reflect a common assumption that internal tools operate outside the scope of accessibility requirements. Or it might simply be that no one checked.

The CORS framework offers a useful lens here. From a community perspective, the people most likely to use this report — compliance officers, product managers, legal teams — include disabled employees who rely on screen readers or keyboard navigation. Accessibility reporting tools are not exempt from accessibility requirements because their audience is internal. From an operational standpoint, the fixes are low-cost and high-signal: fixing the report page demonstrates that the organization's accessibility commitment extends to its own infrastructure, not just its products. From a risk perspective, all seven violations are Level A — the baseline standard that applies under Title III of the ADA (opens in new window) and Section 508 (opens in new window) for covered entities. And strategically, an accessible accessibility report is a credibility statement. It shows that the team building the measurement infrastructure has internalized what they're measuring.

The form at the bottom of this page — the one for updating report recipients — passes every accessibility check. That's real. Build on it.