Accessibility Statement

1.The target

Veyro aims to meet WCAG 2.1 Level AA. That is the target, not a claim of conformance. The sections below separate what has been measured from what has only been designed for, because a statement that blurs the two is worse than none.

2.What has been measured

Colour contrast. Every text colour in the palette was calculated against every background it can appear on. All combinations now meet AA for normal text, worst case 4.55:1.

That audit found a real failure and it has been fixed: the tertiary text colour measured 4.21:1 against the hero band’s background, below the 4.5:1 threshold. It was darkened until every pairing cleared AA.

Structure. Every page has one h1, a single landmark main, and a skip link as the first focusable element. Tables use real table markup with header cells, not stacked divs.

Layout at narrow widths. Every multi-column grid has a rule collapsing it to one column, tables scroll inside their own container rather than widening the page, and nothing carries a fixed minimum width above 360px.

3.What is built in by design

• Form fields are real labelled inputs. Errors are announced with role="alert" and tied to their field with aria-describedby and aria-invalid, so the message reaches a screen reader rather than only being a red outline.
• Interactive elements keep a visible focus indicator. Focus rings are never removed for appearance.
• Touch targets are sized to 44px at mobile widths, above the 24px WCAG 2.2 minimum, because 24px is not a size a thumb reliably hits.
• Motion is minimal, and the stylesheet honours prefers-reduced-motion. There are no animated decorations to disable.
• The eligibility checker and the FAQ work without JavaScript. The FAQ is built from native disclosure elements rather than scripted toggles.

4.What has NOT been tested

Being plain about this matters more than the list above.

• No screen reader testing. Veyro has not been used with VoiceOver, NVDA or JAWS by anyone. The markup is written to be readable by them; that is not the same as knowing it is.
• No testing with assistive technology users. Nobody who relies on one has tried this product.
• No automated accessibility scan has been run in a browser, and no manual keyboard walkthrough has been recorded.
• Stripe’s hosted pages are outside our control. Identity onboarding and the card entry field are Stripe’s, and their accessibility is theirs.

5.Known gaps

• Wide tables scroll horizontally on a phone. Scrolling is better than a broken layout, but it is still a worse experience than a layout that reflows.
• Some status is carried by a coloured badge with a text label. The label is always present, so colour is not the only signal, but the badges have not been checked in a colour-blindness simulator.

6.Tell us

If something here is unusable for you, email hello@withveyro.com and say what you were trying to do. A specific report is worth more than any audit, and it will be treated as a bug rather than a suggestion.

If you cannot complete something because of an accessibility barrier, we will do it with you directly rather than leave you stuck. See also what a guardian takes on, which matters if you are helping someone use this.