# What we enforce, and what we don't.

Source: https://customlabs.io/accessibility/
Updated: 2026-09-08

Accessibility

# What we enforce, and what we don't.

We hold this site to WCAG 2.2 AA. Below is what CI actually checks on every build, and what it doesn't. Same first-party approach as our security review and delivery record: named limits instead of a badge.

The standard

## WCAG 2.2 AA, checked at build time.

An audit of the built site found five buying-path pages shipping with no page heading, no way to skip the navigation, and a menu that was quietly writing itself into the document outline. Those are fixed, and four checks now run on every build so they can't come back unnoticed.

What CI enforces

## Four checks, every build.

Each one fails the build with a readable list of what it found, not a silent pass.

### `verify-a11y`

Every page has exactly one <h1> inside <main>, no heading level skips, no headings outside <main> (so the nav can't reopen the outline), a working skip link, every image has alt text, every link and button has an accessible name, every form control has a label, no positive tabindex, no focusable element nested inside a <summary>, and a 24px floor declared on the heading permalink.

### `verify-seo`

Canonical URLs, structured data, meta descriptions, and page titles are present, correct, and unique on every route. A search engine and a screen reader both depend on the same thing here: an honest, unambiguous description of what the page actually is.

### `verify-theme`

Every text-and-surface colour pairing in both themes clears 4.5:1 contrast, every focus indicator clears 3:1, and no component draws its own focus ring in a colour that skips the check.

### `verify-copy`

Prose density and banned filler phrases, which is not an accessibility rule in the WCAG sense but the same instinct: a reader using a screen reader has to sit through every word we didn't cut.

What isn't automated

## What this doesn't prove.

Read this before the checklist above, not after.

- No automated screen-reader pass. verify-a11y checks the markup a screen reader depends on (headings, labels, names), not what one actually announces.
- No axe-core or other browser-based scanner in CI. The gate is regex over built HTML, the same approach every other verifier on this site uses, so it catches a fixed, named list of defects, not everything axe would.
- Focus order is not machine-checked beyond the skip link. Tab order for on-page content follows document order, but nothing in CI walks a page pressing Tab.
- The scroll-in entrance animations honour a reduced-motion preference, but we have verified that by reading the stylesheet, not by testing it with someone who relies on the setting.
- Keyboard and screen-reader testing here has been done by the people who built the site, not an independent accessibility audit.

Report a problem

## Found something we missed?

Tell us what page, what you were trying to do, and what happened instead. [Send a project brief](https://customlabs.io/contact/) and put "Accessibility" in it. We read every one.