ARIA6: When aria-label Is the Right Tool — and When It Isn't

The W3C's technique catalog for WCAG 2.2 includes hundreds of entries. ARIA6 (opens in new window) is one of the shorter ones. Its description runs fewer than 150 words. That brevity is deceptive — packed inside those 150 words are two precedence rules that, when misunderstood, produce some of the most common and consequential accessible naming errors in production code.

The Technique

ARIA6 describes a sufficient technique for meeting WCAG 2.1 Success Criterion 1.1.1 Non-text Content (opens in new window): use the aria-label attribute to provide a text label for an object when no existing page text can serve that purpose. The classic use cases are navigation landmarks that need disambiguation, region landmarks without visible headings, and mathematical expressions that need a human-readable equivalent alongside their MathML rendering.

The technique is narrow by design. It answers one question: how do you name something when there's nothing on the page to name it with?

Why This Matters

For a screen reader user, an unlabeled navigation landmark is a dead zone. Two <nav> elements on the same page, both announced as "navigation," offer no way to distinguish primary site navigation from a local table-of-contents. The user either explores blindly or skips the region entirely.

The same problem scales to region landmarks, search widgets, data visualizations, and mathematical content. A <div role="region"> with no label is functionally invisible to landmark navigation — most screen readers skip unnamed regions entirely. A MathML expression without an aria-label forces the screen reader to attempt rendering the raw markup, producing output like "m-frac m-n 6 m-n m-n 4 m-n" — technically present, practically useless.

For keyboard users navigating by landmark (a common efficiency strategy for blind users), unlabeled or duplicate-labeled regions create genuine orientation failures. This isn't a minor inconvenience. It's the difference between being able to use a page efficiently and having to read every element sequentially.

How It Works

ARIA6 provides three code examples that together define the appropriate scope of the technique.

Distinguishing navigation landmarks:

<div role="navigation" aria-label="Primary">
  <ul>
    <li>...a list of links here ...</li>
  </ul>
</div>
<div role="navigation" aria-label="Secondary">
  <ul>
    <li>...a list of links here ...</li>
  </ul>
</div>

Labeling a region landmark with no visible heading:

<div role="region" aria-label="weather portlet">
  ...
</div>

Providing a human-readable label for MathML:

<div role="math" aria-label="6 divided by 4 equals 1.5">
  <math xmlns="https://www.w3.org/1998/Math/MathML">
    <mfrac>
      <mn>6</mn>
      <mn>4</mn>
    </mfrac>
    <mo>=</mo>
    <mn>1.5</mn>
  </math>
</div>

All three examples share a structural logic: there is no visible text on the page that could be referenced instead. That condition matters.

The technique document states two precedence rules that teams frequently miss:

1. aria-labelledby takes priority. If both aria-label and aria-labelledby are present on the same element, assistive technologies will use aria-labelledby and disregard aria-label. This is defined in the Accessible Name and Description Computation (opens in new window) specification.

2. aria-label overrides native naming. Applying aria-label to an <img> overrides its alt attribute. Applying it to a form field overrides a properly associated <label> element. This is not additive — it replaces.

These two rules together mean aria-label sits in a specific middle position in the naming hierarchy: it wins over native HTML semantics, but loses to aria-labelledby.

Applying This

For development teams, the practical guidance breaks into three layers.

When to use aria-label: Reserve it for situations where no visible text exists and aria-labelledby isn't feasible. Landmark disambiguation is the canonical case. If there's a visible heading or label already on the page, use aria-labelledby to reference it — that approach keeps the accessible name synchronized with the visible UI automatically.

What to test for in code review:

• Any element with both aria-label and aria-labelledby — the aria-label is dead code
• Any <img> with both alt and aria-label — the alt is being overridden
• Any form <input> with a <label for> association and an aria-label — the visible label is being overridden
• Any page with multiple landmarks of the same type and no distinguishing labels

What automated testing catches — and doesn't: Automated tools can flag missing labels on interactive elements and duplicate landmark types. They cannot determine whether an aria-label value is accurate, meaningful, or consistent with visible content. As our research on testing methodology shows, the gap between automated detection and real-world barrier identification is substantial. ARIA6 failures often live in that gap — technically present labels that don't reflect what a sighted user sees.

For teams working across multiple compliance frameworks, the standards fragmentation research is relevant here: aria-label requirements appear across WCAG 2.1, Section 508, and EN 301 549, but the testing expectations differ. A label that satisfies automated WCAG checking may still fail a manual Section 508 evaluation if the label text doesn't match the visible control name — which implicates Success Criterion 2.5.3 Label in Name, a separate requirement not covered by ARIA6 itself.

The translation problem for MathML: The math example in ARIA6 deserves specific attention for teams building educational or scientific content. The aria-label must be a complete, accurate verbal translation of the expression — not a description of the notation. "6 divided by 4 equals 1.5" works. "Fraction" does not. This requires subject-matter input, not just developer judgment, and it's the kind of quality issue that manual audit methodology is designed to catch.

CORS Perspective

From a strategic alignment lens, ARIA6 is a low-cost, high-dignity fix — but only when applied correctly. The risk isn't in using aria-label; it's in over-applying it as a shortcut that masks underlying structural problems. A development team that reaches for aria-label instead of fixing missing visible labels is trading a screen reader user's equal access for implementation convenience. That's a strategic failure with legal exposure: the DOJ's web accessibility guidance (opens in new window) is clear that equal access to digital services is a Title III obligation, and landmark navigation failures are exactly the kind of systemic barrier that appears in DOJ settlement agreements. The right frame isn't "add an aria-label and move on" — it's "does our page structure support all users, and where aria-label is the answer, is it the best answer available?"