Common Accessible Names mistakes that still ship

Uptime was green. The Lighthouse slide from two weeks ago looked fine. Then the client's accessibility lead shared their screen, focused the header, and the screen reader said "button" four times in a row. That is an Accessible names problem wearing a project-management costume.

SlaySlop's check description matches the embarrassment: it "finds controls and content that lack usable accessible labels." The mistakes below are the ones I still see in launch-week portals. None of them require exotic tooling to understand. They require someone to stop trusting the screenshot.

Outcome if you fix these early

You reduce the chance that a handoff call turns into a live demo of anonymous controls. You also get cleaner tickets: URL, control, missing name, fix. Agencies survive launch week on process that boring.

Boundaries before the blame game

A public read-only scanner will not see controls behind a login you did not include. SlaySlop does not edit the site. Permission is required. Accessible names is one accessibility check among others in the catalog (Accessibility audit, Document semantics, Viewport configuration). Closing name issues does not retire the rest.

Also: a past Lighthouse lab run on a single staging URL is not monitoring. SlaySlop's compare framing against Lighthouse is that Lighthouse is a lab snapshot, while SlaySlop keeps checking a live public site across more categories. Use both honestly. Do not wave an old lab PDF at a new production header.

Happy path: catch the usual suspects on purpose

Walk the shipped chrome in a real browser. Tab order first. Then forms. Then anything that mounts late (consent, chat, promo modals).

# Agency preflight: same URLs you put in the portal
for u in \
  "https://client.example.com/" \
  "https://client.example.com/pricing" \
  "https://client.example.com/blog"
do
  printf 'CHECK %s\n' "$u"
  curl -sI "$u" | sed -n '1,8p'
  printf '\n'
done

The curl loop only proves the URLs answer. The naming pass still happens in the browser (or in a scanner that renders one). Keep both steps so nobody confuses "HTTP 200" with "ready for handoff."

Mistakes that still ship

Icon-only controls with no name

Close, menu, share, search, carousel chevrons. The SVG has aria-hidden, which is correct for the graphic, and the button has nothing else. Fix with visible text or aria-label / aria-labelledby. Make the prop required in the design system if you own the kit.

<!-- Ships constantly -->
<button type="button"><svg aria-hidden="true"><!-- search --></svg></button>

<!-- Survives a client screen share -->
<button type="button" aria-label="Search">
  <svg aria-hidden="true"><!-- search --></svg>
</button>

Placeholder as the only label

Placeholders vanish when the user types. They are also easy to miss in automated assumptions. Pair every input with a real label association.

aria-label set to junk

Empty strings, whitespace, or "button" / "click here" on every card CTA. The attribute exists. The name is not usable. SlaySlop's glossary wording is "usable accessible labels," which is the right standard for ticket acceptance.

Late-mounted UI nobody retested

Cookie banners and chat widgets inject controls after the "we QA'd the page" moment. Marketing modals do the same. Production third-party scripts differ from staging. If your process stops at the first paint of the marketing shell, you will meet these controls on the client call instead.

Clickable cards where the name is the whole paragraph

A card wraps a heading, two sentences, and a fake button in one giant link. The accessible name becomes a speech-dump. Prefer a discrete link with a tight name, or clean labeling so the control announces something a person can parse.

Assuming the CMS "handles a11y"

Most CMS components handle nothing of the sort unless your theme wires labels through. Editors paste icon blocks. The block has no name field. It ships.

Pitfalls in the ops workflow

Filing one ticket for "fix a11y" with no URL. Findings that attach to routes exist so you do not do that. If you use SlaySlop, keep the page link in the ticket title.

Celebrating uptime while quality regressions pile up is a classic agency miss. Monitoring that only pings availability will not notice an unlabeled nav that appeared in yesterday's header deploy. SlaySlop's public framing is closer to: scan for issues, fix what matters, then keep watching after release. Name regressions belong in that post-launch watch list on retainers.

Letting the designer accept the fix in Figma only. The name has to land in the rendered DOM. Recheck production or the exact preview URL you handed the client.

Related next step

Put Accessible names on the pre-handoff checklist next to broken links and missing titles. When a finding appears, fix the control, then scan again on the same URL. For the product definition and catalog placement, use Accessible names and checks. If you need the performance-and-accessibility framing for the client deck, the Performance and accessibility page states the workflow in plain language: render, audit, attach findings to routes, start with the worst.