Document Semantics and false confidence from a quick glance

I still reach for the browser first. A page can look orderly in a screenshot and still offer assistive technology almost nothing to navigate by. SlaySlop's Document semantics check has a narrower meaning than "the layout is clean." The glossary line: it "Reviews structural signals that help assistive technology."

That is the claim. Not "WCAG done." Not "all buttons are labeled." Not "SEO is fine." Structural signals on the rendered public page are a specific question, and the performance and accessibility report keeps it next to related checks.

What a quick glance usually means

Someone scrolls the homepage, sees a hero and a footer, maybe opens Lighthouse once on a laptop, and writes "structure OK" into the portal. Clients hear accessibility. What you measured might have been visual QA.

false_confidence:
  glance: "screenshot looks structured" or "Lighthouse opened once"
  leap: "page is accessible / semantics are fine / AT users are covered"
  actual_check: document-semantics
  actual_claim: reviews structural signals that help assistive technology

What the check actually observes

Performance and accessibility product copy: the site opens in a real browser so runtime and layout behavior can be measured; performance, accessibility, and best-practice checks run on discovered pages; slow, inaccessible, or unstable experiences come first. Document semantics is the structure slice under Accessibility, beside Accessible names, Accessibility audit, and Viewport configuration.

Boundaries that prevent the leap

Read-only. Permissioned. Not a pentest. SlaySlop does not rewrite your templates. A Document semantics row is not:

• Accessible names (usable labels on controls and content)
• Accessibility audit (broader automated checks in a rendered page)
• Viewport configuration (mobile viewport and zoom-safe behavior)
• Proof that every authenticated view was tested
• A WCAG conformance certificate with users

Keep the labels honest. I have written "a11y done" on tickets I later regretted.

Happy path: glance with evidence fields

When I review a report, I want fields a later reader can reuse:

1. Which URLs were in scope.
2. Whether structural signals looked usable after render (landmarks, headings, related semantics).
3. Whether that matches the templates in the SOW.
4. Which sibling check owns the next gap (names, audit, viewport).

# Owned / permissioned page — remind yourself what you are about to inspect
URL=https://staging.example.com/pricing
curl -sI "$URL" | sed -n '1,12p'
# Then open $URL in a real browser and read landmarks + headings

<!-- What I hope to see in the tree, not only in CSS -->
<main>
  <h1>Pricing</h1>
  <h2>Compare plans</h2>
</main>

That local habit is not the SlaySlop check. It is how I keep the glance honest before I write "semantics OK" into a handoff note.

Pitfalls that manufacture calm

It looks nested. Nesting in CSS is not nesting in the accessibility tree.

My Lighthouse score was fine last month. Templates change. Cookie banners change. Domain insights-style "future scans reveal drift" thinking applies to page quality too—rescan the same URLs.

We fixed alt text. Useful, different check family. Document semantics still asks about structure.

Buttons have aria-labels now. That is Accessible names territory. Celebrate it in the right row.

No finding on a deep link. The crawl renders discovered pages. An unscanned template can still be flat. Scope claims to observed URLs.

How to write the note so it stays true

Prefer: "Document semantics on / and /pricing: main landmark present; heading outline reviewed; Accessible names checked separately; not a full WCAG claim."

Avoid: "Fully semantic and accessibility optimized." That sentence fails the same bar as promotional filler I try to cut from my own drafts.

What I refuse to claim from one glance

A tidy Document semantics row does not mean every control has a usable name. It does not mean viewport zoom is safe. It does not mean the Accessibility audit is empty. It does not mean authenticated flows were tested.

I keep those sentences in handoff notes because clients hear "we checked semantics" and invent a full accessibility bill of health. The glossary claim is narrower: review structural signals that help assistive technology. Say that. Then open the sibling that matches the actual symptom.

When a redesign is in flight, I also write which template versions were live at scan time. Without that, every staging URL becomes a conflicting source of truth.

Cutover weekend habits

Redesign weekends are when false calm returns. The new marketing shell ships with prettier cards and the same flat tree. I re-open Document semantics on the agreed URLs after the cutover, not only on the staging host that still had the old semantic layout. If a cookie banner or promo modal mounts late, I include that state in the note so nobody argues from two different renders.

Monitoring and follow-up scans matter here the same way they matter for DNS drift. Page-quality findings go stale when templates change underneath a PDF you exported at launch.

Related next step

After structure looks right on primary templates, read Accessible names and Accessibility audit on the same performance and accessibility pass. Soft links: Document semantics, Accessible names, Performance and accessibility. Soft close: a permissioned SlaySlop scan beats a screenshot folder when you need structural evidence tied to URLs.