Accessible Names: what to verify before client handoff

Handoff decks love screenshots. Screenshots do not announce button names. If a primary control has no usable accessible label in the live DOM, the page can still look "launch ready" in a PDF and fail the first assistive-tech pass the client's team runs.

SlaySlop defines its Accessible names check in one line: it "finds controls and content that lack usable accessible labels." Before you send portal access or a final report, that is the bar I use for naming. Not a slogan. A concrete miss on a concrete URL.

Outcome you want at handoff

Every interactive control on the routes you claim are done should expose a usable accessible name after render. Primary CTAs, form fields, icon buttons in the chrome, cookie banner actions, and mobile nav toggles come first. Footer niceties come later.

This is also an SEO-adjacent hygiene problem in a narrow sense. Crawlers and answer engines care more about titles, meta, and structured data than about aria-label on a share button. People using assistive tech, and an increasing set of automated quality gates, still hit the same public HTML. Thin pages with anonymous controls read as unfinished the same way a missing meta description does. Different audience, same "we shipped the shell and forgot the meaning" failure mode.

Boundaries to state on the call

Say out loud what the scan is and is not. SlaySlop is a read-only public scan. It does not patch the site. It is not a pentest. Permission is required for sites you do not own or manage. A clean Accessible names result does not equal a full WCAG audit with users.

Keep sibling checks in view so nobody treats one green row as the whole accessibility story:

• Accessibility audit: automated accessibility checks in a rendered browser page
• Document semantics: structural signals that help assistive technology
• Viewport configuration: mobile viewport setup and zoom-safe behavior

Those definitions come from SlaySlop's checks catalog and glossary. Quote them if a client asks what was measured.

Happy path checklist before you send the portal

Work the routes you promised, not a random staging path that still has the old header.

1. List the URLs in scope for handoff (home, key landing pages, signup, pricing, contact, app shell if public).
2. Load each in a real browser. SlaySlop's performance and accessibility flow renders key pages first for the same reason: runtime UI is where names fail.
3. Tab through primary actions. Confirm the accessibility tree shows a computed name, not an empty button.
4. Run or review an Accessible names finding list if you already use SlaySlop. Findings attach to the page where the issue was observed, which is what you want in a client thread.
5. Fix anonymous controls. Retest the same URLs. Then share the report or read-only portal.

A practical markup pattern for the controls that usually fail handoff:

<!-- Before: looks fine in a screenshot -->
<button type="button" class="nav-toggle">
  <span class="hamburger" aria-hidden="true"></span>
</button>

<!-- After: usable name for the same control -->
<button type="button" class="nav-toggle" aria-label="Open menu">
  <span class="hamburger" aria-hidden="true"></span>
</button>

# Keep the handoff URL list boring and explicit
cat <<'URLS'
https://client.example.com/
https://client.example.com/pricing
https://client.example.com/contact
URLS

I also paste page titles and meta descriptions into the same pre-flight note. Not because accessible names are an SEO check, but because handoff is when thin metadata and anonymous controls both tend to slip through. SlaySlop's SEO-oriented checks (page title, meta description, and the rest of the catalog) live beside accessibility in the wider report. One pass, fewer "we will fix it in week two" surprises.

Pitfalls that show up on launch week

Placeholder-only inputs. The field looks labeled in the mock. The live input has placeholder="Email" and no <label>. Many teams argue about whether that "counts." Do not argue on launch day. Associate a visible label.

Icon buttons from a shared kit. The design system marks aria-label optional. Every instance ships optional. Make it required for icon-only variants before the next client build.

Cookie and consent UI injected late. The banner mounts after hydration. A static HTML review never sees the dismiss control. Real-browser checks do. SlaySlop's product copy stresses rendered pages for exactly this class of miss.

Duplicate generic names. Ten buttons named "Learn more" are technically named and still useless in a rotor list. The glossary says "usable." Usable means a person can tell controls apart, not merely that a string attribute exists.

Assuming the homepage represents the site. SPAs often hide named route chrome behind client navigation. If the crawl or your manual pass never opens /checkout, you did not verify /checkout.

Related next step

Bundle Accessible names with Document semantics when you walk the client through accessibility rows. A tidy heading outline with anonymous buttons still fails people. Named controls dumped in a sea of unlabelled divs still fail people. The Performance and accessibility product keeps both finding sets in the same route context, which is how you want the conversation ordered: worst inaccessible experiences first, cosmetic cleanup later.

When you need the canonical one-line definition for the check itself, use the Accessible names glossary page and point stakeholders at checks for the rest of the catalog.