Checklist: accessible names on public pages

What an attacker sees on the public surface is not the usual framing for accessibility, but the observation point is the same. If a control has no usable accessible name in the live DOM, assistive tech and automated gates both hit a blank. Screenshots will not save you.

SlaySlop's Accessible names check "finds controls and content that lack usable accessible labels." Glossary and checks catalog agree on that sentence. Performance and accessibility runs render key pages in a real browser before quality audits attach findings to routes.

Outcome

Primary interactive controls on shipped public routes expose usable accessible names after render. Icon-only buttons, nav toggles, cookie banner actions, form fields, and carousel chevrons come first. Decorative noise comes never.

Boundaries

Read-only. Permission required. Not a pentest. Not a full WCAG audit with users. Sibling checks stay in their lanes: Accessibility audit runs automated accessibility checks in a rendered browser page; Document semantics reviews structural signals that help assistive technology; Viewport configuration checks mobile viewport setup and zoom-safe behavior.

Checklist

1. Confirm permission on the host you are about to judge.
2. Identify the routes you claim are done (home, pricing, signup, docs landing, checkout start).
3. Run or open SlaySlop Accessible names findings for those routes after render, not a static HTML-only guess.
4. For each finding, open the page and locate the control. Prefer visible text. Use aria-label or aria-labelledby when the design is icon-only and honest about it.
5. Check cookie and consent chrome. Those controls ship on every page and fail loudly in demos.
6. Check mobile nav toggles at a phone width. Desktop mega-menus hide sins.
7. Recheck after the design system release that "just changed icons."
8. Rescan. Keep Accessibility audit and Document semantics on the board so you do not declare victory from labels alone.

Pitfalls

Relying on placeholder aria-label="button". Labeling desktop controls and shipping an unlabeled mobile FAB. Fixing names in Storybook while production CMS blocks strip attributes. Treating a green Accessible names row as permission to skip keyboard testing with a human.

Related next step

Walk the checklist on the routes in your handoff email. Fix unlabeled controls, rescan, then read sibling accessibility rows. Evidence belongs on the finding; start from a permissioned scan on slayslop.com if you need the route-linked list.

Why this checklist stays short

Long a11y checklists become wallpaper. This one only covers usable naming on public controls after render because that is what the Accessible names row observes. When a finding cites a carousel, do not wander into color contrast mid-ticket. Open a separate Accessibility audit item if the audit row fired.

I also keep a chrome inventory for agencies: cookie banner, chat launcher, language switcher, search icon, account menu. Those five show up on most marketing stacks and produce the same unlabeled-icon pattern. If they are clean, you still check page-unique controls, but you have already removed the demo-day landmines.

If editors publish content blocks with buttons, teach them that empty button text in the CMS becomes an Accessible names finding later. The scan will not care that the design file had a tooltip.

Rescan rule

No Accessible names ticket closes on screenshots alone. Rescan the cited URL. If the control moved to a new route after an IA change, update the evidence link. Stale URLs are how unlabeled buttons survive into the next quarter.