Partial conformance, stated plainly.
Parts of Vows & Volts are tested for accessibility on every push, and parts are not tested at all. This page says which is which. It claims no standard and no conformance level, because we have not done the work that would let us claim one.
Last reviewed against the test suites themselves on 30 September 2026.
What is tested, and how
16 public pages are covered by one or both of the two automated checks below. Both run in continuous integration on every push, and both fail the build rather than filing a warning somebody can ignore.
axe-core, on the rendered page
The same engine Lighthouse uses, run against each page after it has loaded and settled, with the WCAG 2.0 A/AA, WCAG 2.1 A/AA and best-practice rule sets enabled. A violation axe rates serious or critical fails the build. Moderate and minor ones are printed and do not. The cookie banner is audited too, on its first appearance, rather than dismissed before the check runs.
12 pages
//pricing/blog/compare/vendors/tools/tools/seating-chart/tools/table-calculator/sign-in/sign-up/legal/contact
Lighthouse, three runs per page
Each of these pages must score at least 0.9 on Lighthouse's accessibility category, averaged over three runs against a production build, or the build fails. A Lighthouse score is a weighted sample of automated checks, not a grade: it is useful as a floor nothing may drop below, and it is not a measure of whether the page works for somebody.
12 pages
/tools/tools/seating-chart/tools/table-calculator/tools/guest-list/tools/budget-calculator/tools/rsvp-tracker//pricing/blog/blog/wedding-seating-chart-etiquette/compare/vendors
Keyboard tests on the shared form controls
Two unit test suites drive the shared form controls from the keyboard alone: space to toggle, arrow keys to move within a group, Home and End, Enter to open and Escape to close. These controls are reused across the product, including the signed-in parts that have no page-level coverage, so the behaviour they guarantee travels further than the page list above.
- Checkbox, switch and radio group
components/ui/choice-controls.test.tsx - Date picker
components/ui/date-picker.test.tsx
Reduced motion is honoured
The whole app is wrapped in a motion configuration that reads the operating system's “reduce motion” setting, and the stylesheet collapses transitions under the same media query. Animations become instant state changes rather than movement. This is implemented and exercised by the automated sweep, which requests reduced motion in order to audit settled pages; there is no dedicated test asserting that every single animation respects it.
What is not tested
The useful half of a statement like this one. None of the following is covered by anything, and saying so is not an admission we are working around: it is the list we are working from.
- The signed-in product has no automated accessibility coverage
- Everything behind sign-in, the planning dashboard, the guest ledger, the seating canvas, checkout, the vendor and planner workspaces and the admin screens, has no automated accessibility test of any kind. That is the larger half of this product by screen count, and it is the half a customer uses every day. Nothing on this page should be read as applying to it.
- No person has audited this with assistive technology
- There has been no screen reader pass, no keyboard-only walkthrough of a whole task, and no testing with voice control, switch access or magnification. Automated tools find the machine-checkable subset of accessibility problems and are silent on the rest: a heading order that makes no sense, a label that is technically present but misleading, a flow that is operable but exhausting.
- Moderate and minor issues are reported, not blocked
- The automated sweep fails only on serious and critical violations. Moderate and minor ones are printed in the build output and do not stop a release, so some are certainly live right now.
- One browser, one viewport
- The automated checks run in headless Chromium at a desktop viewport. They say nothing about Safari, Firefox, mobile browsers, or how the same page behaves at a phone width or with text scaled up.
- Only the English pages
- The audited paths are the unprefixed English URLs. The German, Spanish, French and Portuguese versions of those pages are not separately audited, and neither are the wedding sites couples publish, whose content they write themselves.
- No conformance level is claimed
- We do not claim WCAG 2.1 A, AA or any other level of conformance, and we have not had an external audit. Passing the checks below is evidence of some things, and it is not a conformance claim. Anyone who needs one should ask us before relying on this page.
Found a barrier? Tell us.
A report from somebody who could not do something is worth more than any of the checks above, and it is the only route by which the untested half of this product gets fixed. Tell us what you were trying to do, what happened, and what you were using: the browser, and the screen reader, keyboard or other assistive technology if any. You do not need to identify the problem in accessibility terms; describing what went wrong is enough.
Report an accessibility problem
We will acknowledge a report and tell you what we find, including when the answer is that we are not going to be able to fix it soon. We do not promise a resolution time we have no track record to support. See also our security page, which reports engineering status the same way this one does.