What evidence should back an accessible names finding

I want evidence that explains the observation, not a color. Accessible names on SlaySlop "finds controls and content that lack usable accessible labels." If the export cannot show which page and what kind of node failed after render, the finding is not ready for a portal headline.

Outcome first

From the attached evidence you should answer: which URL was rendered, which control or content node lacked a usable accessible name, and what the scanner observed on that public page. After a fix, the same packet shape should go quiet on rescan.

Boundaries the evidence must keep visible

Read-only public scan. Permission required. Not a pentest. Not a claim that every ARIA edge case is proven. Automated Accessibility audit findings are siblings, not duplicates. Viewport and Document semantics findings need their own evidence.

SlaySlop does not edit the page for you. Evidence is for humans and coding agents to patch the template, then verify.

Happy path: what to attach

check: Accessible names
glossary: https://slayslop.com/glossary/accessible-names
definition: finds controls and content that lack usable accessible labels
target_url: https://www.example.com/pricing
rendered: real browser session
node_hint: <describe control role / icon button / field>
signal: usable accessible name missing or not usable
siblings_not_included: Accessibility audit, Document semantics, Viewport configuration
notes: "Reproduce after hydration; static curl may miss the node"

Permissioned local reproduce helps engineers trust the packet:

# Authorized host, confirm the route loads; naming still needs a browser
curl -sI "https://www.example.com/pricing" | sed -n '1,15p'

Use DevTools accessibility tree or your stack's testing library on a host you own to confirm the control name after the fix. Keep screenshots as optional garnish. The structured packet is the source of truth.

What good evidence looks like

Good: "On /pricing, the sticky chat launcher button has no accessible name after hydration." Good: "Email field in the footer newsletter form lacks an associated label name." Bad: "Site has accessibility issues." Bad: a Lighthouse score with no node context.

When multiple nodes fail on one route, keep them itemized. Bundling twenty unlabeled icons into one sentence guarantees half will be skipped.

Pitfalls

Pasting only a severity badge into Jira. Citing staging evidence while the client reads production. "Fixing" evidence by deleting the control from the scan paths instead of naming it. Mixing color-contrast audit notes into an Accessible names ticket until nobody knows what to retest.

Related next step

Attach the packet, fix the named control, rescan the same URL. If you need the initial route-linked findings, run a permissioned scan from slayslop.com and export the evidence with the finding.

How fix prompts should consume the evidence

When you paste a fix prompt into Cursor, leave the URL and node hint intact. Agents that receive only "add aria labels everywhere" will spray worthless attributes across the design system. Agents that receive the packet above tend to edit the cited control.

After rescan, attach the new evidence state to the ticket, even when clear. Auditors and clients ask what changed. A cleared Accessible names row with a before/after route note is enough. You do not need a novel.

If the node only exists after hydration, write that in the notes field. Otherwise the next engineer will curl the HTML, see nothing, and close the ticket as a false positive while the live page stays broken.

Cross-check with viewport

If the unlabeled control only exists in the mobile menu, note viewport width in the packet. Otherwise desktop-only reviewers will miss it. Viewport configuration findings may sit beside the names row; they do not replace naming evidence.