How SlaySlop checks Accessible Names

I care less about the slogan for an accessibility check and more about the observation point: which surface the scanner reads, what counts as a miss, and which page the finding points back to.

For Accessible names, SlaySlop's published definition is short. The check "finds controls and content that lack usable accessible labels." The rest of this post hangs off that sentence and the product pages that describe how quality audits run.

Outcome the check is for

You want a list of public-page controls (and related content) whose accessible name did not resolve to usable text after the page rendered. The outcome is not a WCAG certificate. It is a ranked finding with a page attachment so you can open the route and inspect the control.

SlaySlop groups this check under accessibility, alongside Accessibility audit ("runs automated accessibility checks in a rendered browser page"), Document semantics ("reviews structural signals that help assistive technology"), and Viewport configuration ("checks mobile viewport setup and zoom-safe behavior"). Accessible names is the labeling slice of that set.

Boundaries

Read-only. Public surface. Permission required. The product summary is explicit: SlaySlop runs read-only checks on public websites; it does not edit code, content, settings, or data on the target; scanning a site you do not own, manage, or have permission to test violates Acceptable Use.

The check is also not a claim about every possible naming edge case in the ARIA spec. "Usable accessible labels" is the product language. I treat that as "the name string assistive tech would rely on is missing or not usable," not as a promise that every naming algorithm quirk is enumerated in the UI.

A static fetch is the wrong observer for this signal. Icon buttons mounted after hydration never appear in the first HTML body. The Performance and accessibility product flow starts with "Render key pages": the site opens in a real browser so runtime and layout behavior can be measured. Accessible names only makes sense after that render.

Happy path: how the signal is observed

Published workflow on the Performance and accessibility product page:

1. Render key pages in a real browser.
2. Run quality audits (performance, accessibility, and best-practice checks) on discovered pages.
3. Attach findings to routes so each issue stays linked to the page where it was observed.
4. Start with the worst: slow, inaccessible, or unstable experiences before cosmetic cleanup.

Accessible names participates in that accessibility pass. The observation target is the rendered page, not the bare response headers. Evidence per issue is part of the product framing: each finding explains the signal and the affected page.

When I reproduce locally before or after a scan, I mirror the same idea: load the page, then inspect the accessibility tree for the control.

# Remind yourself which host you are about to open in a browser
printf '%s\n' "https://staging.example.com/pricing"

# Optional: confirm the document responds before a manual a11y pass
curl -sI "https://staging.example.com/pricing" | awk 'NR<=15 {print}'

HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: public, max-age=0, must-revalidate

Headers only tell you the document arrived. The name check cares about nodes after paint and script. In DevTools, focus a suspect control and read the computed name. Empty name on a button or link is the human-readable version of what the glossary describes.

A minimal failing pattern in markup looks like this:

<button type="button" class="icon-btn" data-action="share">
  <svg width="20" height="20" aria-hidden="true"><!-- ... --></svg>
</button>

Nothing in that tree yields a usable name. Adding visible text, an associated label, aria-label, or aria-labelledby changes the observation.

Pitfalls in interpreting the result

"No Accessible names finding" is not the same claim as "the page is accessible." Document structure can still be wrong. A broader Accessibility audit can still flag other automated issues. Keyboard traps will not show up just because every button has a string.

Placeholder text is a weak proof of a name. Many browsers expose placeholders differently from labels. Usable labeling usually means a real <label>, aria-labelledby, or equivalent, not a gray hint that disappears on type.

Coverage is also easy to over-read. If you only scanned a deep link that never mounts the shell navigation, the finding list will not invent header controls for you. Findings attach to observed pages. What the crawl rendered and discovered is the scope. Controls behind an authenticated wall stay out of a public read-only scan, which matches the product boundary.

Synonym cycling in tickets is another trap. "A11y label," "ARIA name," "accessible name," and "accName" refer to the same idea here. Pick one term in the bug report and paste the page URL from the finding.

Related checks and next action

If Accessible names fires on a primary CTA, fix that before debating footer link prose. The product guidance is to start with the worst inaccessible experiences. Pair the fix with a quick Document semantics glance when the control sits in a landmark-less soup of divs. Then rescan the same URL; SlaySlop's broader product language includes follow-up scans to check whether an issue still appears.

Catalog references worth keeping open while you debug: Accessible names, Document semantics, Accessibility audit, and the checks index.