Document Semantics: what to verify before client handoff

Handoff decks love screenshots. Screenshots do not expose landmarks. If a primary template has no usable structural map 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 Document semantics check in one line: it "Reviews structural signals that help assistive technology." Before you send portal access or a final report, that is the bar I use for structure. Not a slogan. A concrete miss on a concrete URL.

Outcome you want at handoff

Every in-scope template should expose usable structural signals after render: a clear main region, navigation that presents as navigation, a heading outline that matches the content story, and native elements that match their jobs. Home, key landing pages, signup, pricing, and contact come first. Blog pagination chrome can wait.

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 a main landmark. People using assistive tech, and an increasing set of automated quality gates, still hit the same public HTML. Thin pages with flat structure 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 Document semantics 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
• Accessible names: controls and content that lack usable accessible labels
• 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 shell.

1. List the URLs in scope for handoff.
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 structure fails.
3. Confirm a main (or equivalent landmark), primary nav, and a heading outline that a human could navigate.
4. Run or review a Document semantics finding list if you already use SlaySlop. Findings attach to the page where the issue was observed.
5. Fix structural gaps. Retest the same URLs. Then share the report or read-only portal.

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

<!-- Before: looks fine in a screenshot -->
<div class="page">
  <div class="top-links"><!-- ... --></div>
  <div class="title">Contact</div>
  <div class="form"><!-- ... --></div>
</div>

<!-- After: structural signals assistive tech can use -->
<header>
  <nav aria-label="Primary"><!-- ... --></nav>
</header>
<main>
  <h1>Contact</h1>
  <form><!-- ... --></form>
</main>

# 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 document semantics are an SEO check, but because handoff is when thin metadata and flat structure both tend to slip through. SlaySlop's SEO-oriented checks 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

Design-system heroes that never use headings. Every landing page recycles a div.hero-title. Visual QA stays green. Heading navigation stays empty.

App-shell routes scanned once on an empty state. The crawl never mounted the authenticated chrome you showed in the demo. Public handoff should only claim public routes.

Collapsing Document semantics into Accessible names. Fixing aria-label on icon buttons does not create a main landmark. Keep separate tickets when both fire.

Calling the Accessibility audit "done" because Lighthouse was opened once locally. SlaySlop's Accessibility audit "Runs automated accessibility checks in a rendered browser page." Document semantics is still its own glossary row. Quote both if the client asks what shipped.

Skipping viewport. Zoom-hostile viewport meta is a different check. Do not bury it inside a structure conversation.

How I write the portal note

Prefer:

Document semantics: reviewed structural signals on <URL list>.
Findings: <none|list by URL>. Sibling checks: accessible names, accessibility audit, viewport.
Not claimed: full WCAG conformance with users.

Avoid: "Fully accessible and SEO optimized structure." That sentence fails the same editorial bar as a keyword-stuffed title tag.

Ownership of templates after you leave

Somebody has to own the shared layout that emits header, nav, main, and heading primitives. I write that name into the handoff packet even when it is "the client design system lead." Ambiguity here recreates div-only heroes the first time a campaign page is cloned from an old Figma frame.

Related next step

Keep Document semantics next to Accessible names in the same performance and accessibility pass. Soft links: Document semantics, Accessible names, Performance and accessibility. Soft close: a permissioned SlaySlop scan beats a PDF of screenshots when you need structure findings tied to URLs.