Icon Buttons Without Names: A Play/Pause Audit

"SVG icon button without accessible name or state." That's the bug description on this test page (opens in new window) — and it's also a near-perfect summary of one of the most common interactive component failures in production web applications. Play/pause controls appear everywhere: video players, audio widgets, podcast embeds, media carousels. And they fail in remarkably consistent ways.

The automated analysis of this page identified three violations. Two of them — missing landmarks — are structural. One is functional: a button with no accessible name. That functional failure is the one that stops people cold.

The Finding

The analysis flagged these issues on Bug 40: Icon Button — Play/Pause (opens in new window):

1. Button has no accessible name — empty text content, no aria-label, no aria-labelledby
2. No <nav> landmark — navigation, if present, is unmarked
3. No <header>/banner landmark — page structure is incomplete

The page demonstrates three button patterns side by side. The first — labeled "Video Title" — is the broken one: an SVG icon with no text alternative. The second and third buttons (the emoji-based ⏯️ and ⏹️ controls) pass the accessible name check, which reveals something instructive: emoji characters do carry accessible names via Unicode descriptions, while SVG paths carry nothing unless you add it explicitly.

The problematic pattern looks like this:

<!-- Bug: SVG Icon No aria-label -->
<button>
  <svg><!-- play icon path --></svg>
</button>

A screen reader hits this button and announces... "button." Nothing else. No label. No state. No indication of what pressing it will do.

The relevant WCAG criteria:

• WCAG 4.1.2 Name, Role, Value (opens in new window) — user interface components must have names that can be determined programmatically
• WCAG 1.1.1 Non-text Content (opens in new window) — non-text content (including SVG icons) requires a text alternative
• WCAG 1.3.6 Identify Purpose (opens in new window) — at Level AAA, purpose of UI components should be programmatically determinable, but the spirit applies here

The missing landmarks violate WCAG 1.3.1 Info and Relationships (opens in new window) and WCAG 2.4.1 Bypass Blocks (opens in new window) — structural information that exists visually should be conveyed programmatically.

Why This Matters

For a screen reader user, an unlabeled button in a media player is genuinely disorienting. JAWS, NVDA, and VoiceOver will all announce "button" — leaving the user to guess whether pressing it starts playback, stops it, or does something else entirely. In a page with multiple media controls, this becomes a navigation puzzle with no solution.

The state problem compounds the name problem. Even if the button had a label, this pattern announces no state change when activated. A user presses what they hope is "Play," hears "button" again on focus return, and has no confirmation that anything happened. They're left guessing whether the audio started, whether they need to press again, or whether the control is broken.

Switch users and keyboard navigators face a related issue: without semantic structure (landmarks), they lose the ability to efficiently orient within the page. Landmark navigation is a primary strategy for screen reader users moving through complex pages — <header>, <main>, <nav> are the skeleton that makes jump navigation possible.

This isn't a hypothetical barrier. Media players are high-engagement, high-frequency interfaces. Research on automated vs. manual testing methodology consistently shows that interactive state failures — exactly like this play/pause pattern — are among the issues automated tools catch least reliably. This page's static analysis caught the missing name, but dynamic state behavior (does the label update when playing begins?) requires manual or runtime testing to verify.

Best Practices

The fix for the unlabeled SVG button is straightforward. Add aria-label directly, or use a visually hidden text element:

<!-- Option 1: aria-label -->
<button aria-label="Play video" aria-pressed="false">
  <svg aria-hidden="true" focusable="false">
    <!-- play icon path -->
  </svg>
</button>

<!-- Option 2: visually hidden text -->
<button>
  <svg aria-hidden="true" focusable="false">
    <!-- play icon path -->
  </svg>
  <span class="sr-only">Play video</span>
</button>

Note the aria-hidden="true" and focusable="false" on the SVG. Without these, some browsers expose the SVG to the accessibility tree separately, creating duplicate or confusing announcements. The SVG is decoration — the button's label carries the meaning.

For toggle state, aria-pressed is the right pattern. Update it dynamically as state changes:

button.addEventListener('click', () => {
  const isPlaying = button.getAttribute('aria-pressed') === 'true';
  button.setAttribute('aria-pressed', String(!isPlaying));
  button.setAttribute('aria-label', isPlaying ? 'Play video' : 'Pause video');
});

This gives screen readers two complementary signals: the label updates to reflect current action ("Pause video" when playing), and aria-pressed communicates current state. The ARIA Authoring Practices Guide on toggle buttons (opens in new window) covers this pattern in detail.

For landmarks, the fix is structural:

<header role="banner">
  <!-- site header content -->
</header>

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

<main>
  <!-- page content -->
</main>

HTML5 semantic elements (<header>, <nav>, <main>) create implicit ARIA landmarks. The role attributes shown above are redundant in most contexts but explicit for clarity.

Applying This

For development teams, this pattern surfaces a useful rule: any interactive element that uses an icon — SVG, icon font, or image — needs an explicit accessible name. No exceptions. This is a code review checkpoint that can be enforced with a simple question: "What does a screen reader announce when focus lands here?"

Automated tools like axe-core (opens in new window), Lighthouse, and IBM Equal Access Checker will catch missing button names reliably. Add them to your CI/CD pipeline and this class of error stops shipping. The landmark gaps are similarly detectable — most automated scanners will flag pages missing a <main> or <header>.

The harder problem is dynamic state. The test page description notes that the state change is not announced — that's a runtime behavior, not a static markup issue. As our research on testing methodology documents, automated tools catch static structure but miss interaction patterns. Testing play/pause state announcements requires a screen reader, a real browser, and a human listener.

For design systems teams: if your component library ships a media player or icon button component, the accessible name and state pattern should be baked in — not left to individual implementers. A single well-built component fixes this class of issue everywhere it's used.

CORS Perspective

Through an operational capacity lens, this finding is encouraging precisely because the fix is low-cost and high-leverage. Adding aria-label and aria-pressed to a button component is a 30-minute implementation task — but if that component is used across dozens of media embeds, the impact scales immediately. The real organizational challenge isn't the technical fix; it's building the review process that catches unlabeled icon buttons before they reach production. Teams that integrate axe-core into their CI pipeline and add "accessible name" to their component API checklist will stop seeing this class of bug. The landmark gaps are even simpler — they're template-level fixes that require no component work at all. The genuine progress here is that these patterns are now well-documented, tooling support is strong, and the gap between "broken" and "fixed" is measured in lines of code, not months of work.