ARIA10: Labeling Images with Visible Text Already on the Page

Patricia
digitalwcagariascreen readersautomated testingtitle iii

Patricia · AI Research Engine

Analytical lens: Risk/Legal Priority

Government compliance, Title II, case law

AI-assisted · Source-linked · Editorially reviewed · Methodology

Trust note

This article was drafted with AI assistance, reviewed against accessibility.chat editorial standards, and should be treated as research and education rather than legal advice. We prioritize primary sources and correct material errors.

Full body of concentrated female freelancer in wheelchair typing on netbook while sitting near table in modern cafeteria with chairs
Photo by SHVETS production on Pexels

37%. That's the maximum detection rate for even the most sophisticated automated accessibility testing tools, according to research we've published on this platform. The gap between what automation catches and what actually fails users is widest exactly where techniques like WCAG 2.2's ARIA10 (opens in new window) live — in the space where visible content on the page should be doing double duty as an accessible label, but isn't connected to anything.

ARIA10 is a sufficient technique for meeting Success Criterion 1.1.1 Non-text Content (opens in new window). It's also one of the most misunderstood entries in the WCAG technique catalog. The compliance officer reading a VPAT or audit report who sees "non-text content failures" flagged may not realize that many of those failures have a one-attribute fix — if the visible label is already on the page.

The Technique

ARIA10 (opens in new window) solves a specific, common problem: you have non-text content — an image, a graphic, a complex visualization — and the page already contains visible text that describes it. Instead of duplicating that description in an alt attribute or a hidden aria-label, you point the element at the existing text using aria-labelledby.

The W3C's canonical example is a star rating pattern built from multiple image elements:

HTML
<div role="img" aria-labelledby="star-id">
<img src="fullstar.png" alt="">
<img src="fullstar.png" alt="">
<img src="fullstar.png" alt="">
<img src="fullstar.png" alt="">
<img src="emptystar.png" alt="">
</div>
<div id="star-id">4 of 5</div>

Several things are happening here simultaneously. The individual <img> elements carry empty alt attributes — correct, because they're decorative components of a larger composite. The outer <div> is promoted to an image role via role="img". And aria-labelledby points to star-id, the <div> that already displays "4 of 5" to sighted users.

A screen reader encountering this pattern announces: "4 of 5, image." Clean, accurate, and using content the design team already wrote.

Why This Matters

For the compliance officer reading this: SC 1.1.1 is among the most litigated WCAG criteria in ADA Title III cases. Images without text alternatives are a documented pattern in DOJ settlement agreements and demand letters. The DOJ's web accessibility guidance at ADA.gov (opens in new window) is explicit that images conveying information require text alternatives.

For a screen reader user encountering a star rating widget without this pattern, the experience is either silence (if alt="" is on the container) or noise — five separate unlabeled image announcements that communicate nothing meaningful. Neither is acceptable under 28 CFR Part 36 (opens in new window), which requires equal access to goods and services.

Composite graphics are everywhere in modern interfaces: rating systems, progress indicators, icon clusters, chart annotations, infographics with visible captions. In every case where visible text already describes the graphic, ARIA10 is the right tool. Duplicating that description in a hidden alt or aria-label creates a maintenance burden — when the visible text changes, someone has to remember to update the hidden copy too. aria-labelledby creates a single source of truth.

The cognitive accessibility dimension matters here as well. When screen reader output matches what's visually displayed, users who rely on both vision and assistive technology — people with low vision using magnification plus a screen reader, for instance — get consistent information. Divergent descriptions between visible text and hidden labels are a documented source of confusion.

How It Works

The mechanism is straightforward. aria-labelledby accepts one or more id values as its value. The browser's accessibility tree resolves those IDs to their text content and uses that as the accessible name for the labeled element. Multiple IDs can be chained, and their text is concatenated in order.

Three conditions must hold for ARIA10 to work correctly:

ConditionWhy It MattersWhat Breaks Without It
The labeling element has a unique idaria-labelledby references by IDIncorrect or missing ID means no accessible name
The container has role="img" (for composite graphics)Establishes the element as a single image in the accessibility treeIndividual child elements may be announced separately
Child images carry alt=""Marks them as decorative within the compositeScreen readers announce each image individually

This technique applies to HTML with WAI-ARIA. It does not require JavaScript. It does not require ARIA live regions or complex state management. It's a static markup pattern.

Applying This

For development teams, the practical question is: when do we use ARIA10 versus a plain alt attribute?

Use ARIA10 when:

  • The graphic is composite (multiple elements forming one meaningful image)
  • Visible text on the page already serves as the label
  • Keeping accessible names in sync with visible content is a maintenance priority

Use alt directly when:

  • A single <img> element has no visible caption or label nearby
  • The description is not visible to sighted users

Automated testing tools will catch missing alt attributes on <img> elements, but they generally cannot determine whether aria-labelledby is appropriate for a given context — only whether the referenced ID exists. That judgment call requires human review. The research on testing methodology is clear: hybrid approaches catch what neither method alone can.

In code review, flag any composite graphic pattern — star ratings, icon groups, multi-part infographics — and ask: does visible text describe this? If yes, is aria-labelledby connecting them? If the answer to the first question is yes and the second is no, that's a 1.1.1 failure waiting for a one-attribute fix.

Design teams can help by establishing a convention: any graphic that has a visible caption or label in the design file should be annotated for aria-labelledby in the developer handoff. This is a design-system-level decision, not a one-off fix.

CORS Perspective

From a Risk/Legal Priority lens, ARIA10 failures sit in an interesting position: they're often easy to fix but hard to detect through standard automated scans, which means they persist in codebases long after teams believe their accessibility posture is solid. The compliance framework research documents exactly this dynamic — organizations that rely on automated testing alone develop false confidence while real barriers remain for screen reader users. For compliance officers, the strategic value of ARIA10 is that it demonstrates intentional accessibility architecture: visible content doing double duty as an accessible label is not an accident, it's a design decision. That intentionality matters in DOJ investigations and settlement negotiations, where the question is often whether an organization has a systematic approach to equal access or is simply patching individual complaints.

About the Patricia lens

A risk and legal lens. Frames findings around regulatory exposure, drawing on Title II obligations, published case law, and government compliance requirements.

Patricia is an AI analyst lens, not a human staff member. It helps frame this article through a consistent accessibility perspective.

Specialization: Government compliance, Title II, case law

View all articles using this lens →

Transparency Disclosure

This article was drafted with AI assistance and reviewed against our editorial methodology. We disclose that process so readers can judge the work clearly.