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.
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.
Each one fails the build with a readable list of what it found, not a silent pass.
verify-a11yEvery 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-seoCanonical 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-themeEvery 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-copyProse 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.
Read this before the checklist above, not after.
Tell us what page, what you were trying to do, and what happened instead. Send a project brief and put "Accessibility" in it. We read every one.
Source: https://customlabs.io/accessibility/