Accessible Name Tickets for Buttons, Links, and Fields

Accessible-name findings become fixable when the ticket names the exact control, the name exposed to assistive technology, the visible cue users rely on, and the task that breaks when those do not line up.

Use this guide for empty buttons, missing form labels, icon-only controls, repeated product-card links, overwritten button text, generic ARIA labels, and controls where the visible label does not match the programmatic name.

Draft the accessible-name ticket first

Open a product-card empty-button finding in the generator with source, impact, evidence, retest steps, and acceptance criteria already filled in.

Open this accessible-name finding in the generator

What to capture from the finding

Control: button, link, field, menu item, tab, icon button, card CTA, custom select, or landmark.
Visible cue: the exact visible text, icon meaning, nearby heading, product name, field placeholder, or component label.
Accessible name: what the browser accessibility tree, screen reader, scanner, or voice-control test exposes.
Repeated context: product card, search result, table row, account menu, checkout step, language, responsive state, or loading state.
User task: what users are trying to activate, identify, compare, submit, save, delete, filter, or recover from.

Ticket structure

Title:
[Severity] Page or component: control has a missing or misleading accessible name

User impact:
Explain which users cannot identify or activate the control and what task becomes blocked, ambiguous, or error-prone.

Evidence:
- Page or flow:
- Control type:
- Visible text or visual cue:
- Accessible name currently exposed:
- Selector or component:
- State or viewport:
- Scanner or assistive technology result:

Likely WCAG references to verify:
- 4.1.2 Name, Role, Value, when the control lacks a usable programmatic name or exposes the wrong role/state.
- 2.4.6 Headings and Labels, when labels do not describe topic or purpose.
- 2.5.3 Label in Name, when visible text is not included in the accessible name.
- 3.3.2 Labels or Instructions, when a form control's purpose or required input is unclear.

Acceptance criteria:
- The control exposes a stable accessible name that describes the visible purpose or action.
- Visible text is included in the accessible name when visible text exists.
- Repeated controls include enough context to distinguish their destination or action.
- The fixed component is retested in the affected state, viewport, and assistive technology path.

Paste your accessible-name note into the generator when you want this structure drafted from raw scanner or audit evidence.

Example conversion: empty icon button

Raw finding:
WAVE error: Empty button
Page: product listing
Element: button.product-card__wishlist
State: default product grid

Developer ticket:
[High] Product listing: wishlist icon button has no accessible name

User impact:
Screen reader users encounter an unlabeled button in each product card and cannot tell whether the control saves, removes, compares, or opens product details.

Evidence:
- WAVE reports Empty button on button.product-card__wishlist.
- The visible control is a heart icon inside repeated product cards.
- The user task is saving a product from the listing for later.

Likely WCAG references to verify:
- 4.1.2 Name, Role, Value
- 2.4.6 Headings and Labels

Acceptance criteria:
- Each wishlist button exposes a name such as "Add [product name] to wishlist".
- The saved or unsaved state is exposed where the same control toggles state.
- Keyboard and screen reader users can identify the control before activation.
- The shared product-card component is retested across representative listing pages.

Generate a draft ticket from this empty-button finding

Example conversion: visible label overwritten by ARIA

Raw finding:
Checkout button visibly says "Place order", but the accessibility tree exposes "Submit" because aria-label overrides the visible text.

Developer ticket:
[Critical] Checkout review: Place order button exposes the wrong accessible name

User impact:
Speech input users may be unable to activate the primary checkout action by saying the visible button text, and screen reader users hear a generic action that does not match the page.

Evidence:
- Flow: checkout review
- Visible label: Place order
- Accessible name: Submit
- Cause to inspect: aria-label overrides native button text
- Spoken command tested: click Place order

Likely WCAG references to verify:
- 2.5.3 Label in Name
- 4.1.2 Name, Role, Value

Acceptance criteria:
- The accessible name contains the visible text "Place order".
- The control remains a native button or exposes the correct button role.
- Loading and disabled states do not replace the name with generic text.
- Voice control can activate the control by its visible label.

Example conversion: missing field label

Raw finding:
Lighthouse reports form element does not have an associated label for input[name="search"]. The visual field uses placeholder text "Search products".

Developer ticket:
[Medium] Product search: search field relies on placeholder text instead of a persistent label

User impact:
Screen reader users may not hear a reliable field purpose, and users with cognitive or memory impairments can lose the cue after typing because placeholder text disappears.

Evidence:
- Page: product listing
- Field: search input
- Current cue: placeholder text only
- Tool: Lighthouse form label audit
- User task: searching the product catalog

Likely WCAG references to verify:
- 3.3.2 Labels or Instructions
- 4.1.2 Name, Role, Value
- 2.4.6 Headings and Labels

Acceptance criteria:
- The search field has a persistent visible or programmatic label.
- Placeholder text is not the only source of the field purpose.
- The field's accessible name matches the visible purpose.
- The fix is retested with keyboard, browser inspection, and the original scanner.

Common weak notes to rewrite

"Button has no label": name the visible icon or surrounding card context and the action users need to understand.
"ARIA label wrong": quote both the visible text and the computed accessible name.
"Screen reader says button": include the selector, page state, and whether the control is repeated.
"Links are confusing": separate repeated destination problems from link-purpose wording problems.
"Missing form label": state whether a placeholder, adjacent text, fieldset, legend, or visible label already exists but is not associated.

Paste-ready input for the generator

Accessible-name finding:
Page or flow:
Control type:
Visible text or visual cue:
Accessible name currently exposed:
Selector or component:
Repeated context:
State or viewport:
Scanner or assistive technology result:
User task:
Expected name:
Acceptance criteria needed:

Open the accessibility ticket generator and paste this structure with the audit note.