ARIA Discipline on Hydrogen: Badges, Cards, and Names Scanners Miss

Part 1 of this Converge Accessibility series—Green Scans Aren’t Enough—showed why green Lighthouse and axe scores are a floor, not a finish line. Part 2 covered Load More choreography. This post is about the quieter failures: ARIA that looks helpful and is wrong.

On furniture ecommerce Hydrogen storefronts, promo badges, sale chips, star ratings, and product cards accumulate ARIA the way drawers accumulate dust. Some of it helps. A lot of it creates nameless buttons, double announcements, useless tab stops, or roles that violate ARIA authoring practices—exactly the class of issue Converge Accessibility WCAG 2.2 auditors catch and scanners often shrug at until after you “fixed” the announcement.

The craft rule worth printing

When ARIA fights you: no ARIA is better than bad ARIA.

Native HTML—buttons, links, headings, lists, fieldsets—already carries roles and names. Every extra aria-label, role, or aria-* state is a promise you must keep across React remounts, Oxygen previews, and sibling brands. Broken promises become screen-reader traps.

Promo badges and sale chrome

Sale badges (“Save 20%”, “Floor sample”, “Exclusive”) are visual sugar. Assistive tech needs them to be either part of the product name deliberately, or decorative and silent—not a random third tab stop.

Patterns that failed expert review more than once:

• Badge as a focusable div with an aria-label. Creates a tab stop that announces a promo but does nothing. Shoppers think it is a filter or a link.

• Badge text duplicated in aria-label on the card link. VoiceOver reads “Save 20% Save 20% Queen Hybrid…” depending on browse vs Tab. Acceptance criteria must pick a mode.

• Color-only meaning. Red sale chips without text or accessible name. Scanners may pass contrast on the chip and still leave the meaning inaccessible.

Remediation that held up: keep badge text visible in the DOM as plain text inside the card, fold the promo into the accessible name of the product link once when marketing insists it is primary, and never make the badge itself a widget unless it actually filters or navigates.

Product cards: names, roles, and double talk

A product card is a composition—image, title, price, rating, badge, quick-add. Composition is where illegal ARIA thrives.

• Card wrapper with role="link" wrapping a real <a>. Nested interactive semantics. Keyboard users get odd focus rings; VoiceOver may announce the link twice.

• aria-label on a generic container (no role, or role="group" abused). Authoring practices disallow naming some roles; scanners eventually flag what a “passing announcement” papered over.

• Star ratings without accessible names. Visual stars with empty or “image” alt text. Shoppers hear nothing—or hear five unlabeled graphics.

• Sale prices as ambiguous strings. “From $A $B” without clarifying which is current vs compare-at. Auditors hear confusion; sighted users see strikethrough.

Prefer one primary link for the product title (or a single card link with carefully structured children that are not separately focusable). Give ratings a concise accessible name (“Rated 4.5 out of 5 based on 128 reviews”). Spell out price relationships in text, not only in CSS decoration.

Illegal and incorrect ARIA scanners miss—until they don’t

Expert audits and later automated passes form a loop. After a VoiceOver pass “fixed” a promo pattern, a SortSite/axe run flagged an illegal aria-label on a generic role—proof that a good-sounding announcement can still violate ARIA and leave a useless tab stop.

Watch for:

• Naming roles that must not be named that way (or labeling presentational elements).

• Required owned elements missing for composite roles you copied from a design-system example.

• State attributes that lie—aria-expanded, aria-selected, aria-pressed out of sync with visual UI after a React state race.

• Landmark spam—multiple banner / contentinfo roles from nested Hydrogen headers and footers. Valid in isolation; noisy as a document outline.

Treat re-scan after manual passes as mandatory. Illegal ARIA and contrast regressions sneak in behind “good” announcements.

Selected and expanded state without theater

Size buttons, multi-select options, and store pickers often look “active” visually while announcing as nameless buttons—or never declaring that a choice stuck. That was a Converge finding cluster in post 1; the ARIA fix is discipline, not decoration:

1. Use a real <button> (or properly owned radio/checkbox pattern).

2. Expose state with the matching ARIA attribute and visible text/CSS that does not rely on color alone.

3. Ensure the accessible name includes the option value (“Queen, selected”), not a bare “selected.”

4. Retest with Tab and with VoiceOver browse—card and option patterns diverge between modes.

A short ARIA checklist for Hydrogen PRs

1. Can native HTML do this without ARIA? If yes, delete the ARIA.

2. Does every aria-label sit on an element with an appropriate role?

3. Is there exactly one accessible name path for the product card’s primary action?

4. Do badges and ratings add information once—not three times?

5. Did you re-run axe/SortSite after the VoiceOver pass?

6. Will this markup ship through a shared package so sibling brands inherit the fix?

What’s next

Post 4 closes the series: one Converge backlog across multiple Hydrogen brands without forking themes forever—shared packages, ownership triage, and how to stop fixing the same illegal ARIA twice.

If auditors are handing you ARIA findings your scanners never mentioned, we should talk. Endertech pairs Converge Accessibility remediation with Hydrogen storefront engineering. Start at endertech.com/contact or our Shopify Hydrogen solutions.

Series note: Client brand names are anonymized. Converge Accessibility is named with approval as the contracted expert auditor. Pattern details are paraphrased from internal remediation—not pasted from tickets.