Accessibility
Last updated September 14, 2026.
Is Crate accessible?
Crate is built to the Web Content Accessibility Guidelines 2.2 at level AA, and that target is a commitment rather than a certificate: no independent audit has been carried out, so nothing on this page is an audited conformance claim. What is in place is concrete and checkable. Every page carries a skip link to a real main landmark, declares its language, keeps interactive controls at 44 pixels, sizes form inputs at 16 pixels so a phone does not zoom the page, gives every focusable control a visible focus ring, and settles animation to a static readable state when a visitor asks their system for reduced motion. Merchant storefronts inherit all of that, and the parts a merchant writes themselves are named below.
The four answers a review asks for first
Each one is stated again in full below, with the reason it is true.
-
The standard
WCAG 2.2 level AA, across the marketing site, the merchant dashboard and every storefront Crate renders.
-
The evidence
Self assessment against the published guidelines. No independent audit, no audit report and no VPAT.
-
Where a merchant's choices land
Alt text, product photography, accent colours and any custom code are the merchant's. Crate ships accessible defaults and cannot vouch for what replaces them.
-
Telling us something is broken
Write to the address further down this page. You get a reply from a person inside five working days, carrying a fix or a date.
What is in place, and how it was checked
Written for the person filling in the accessibility row on a procurement questionnaire.
Getting to the content
Every page begins with a skip link. It is visually hidden until it takes focus, so the first press of the Tab key on any page reveals it. It points at the page's main landmark, which is a real element with an id and a tab index, so the jump moves keyboard focus rather than only scrolling the viewport. A skip link that moves the scroll position and leaves focus stranded in the header is the most common way this control ships broken, and it is the reason the target carries a tab index at all.
Every page declares its language on the root element, and the value follows the locale the page actually rendered in rather than being pinned to English. A screen reader chooses its pronunciation from that attribute, so a page that lies about its language is read aloud in the wrong voice.
Keyboard and focus
Everything that can be operated with a pointer can be operated from the keyboard, in the order the content reads. Focus is never removed without a replacement: rings are drawn on the focus-visible state, so they appear for a keyboard visitor and stay out of the way of a mouse visitor, and they are drawn with an offset so the ring stays legible against a dark control as well as a light one.
Menus, drawers and dialogs return focus to the control that opened them when they close, and none of them hold focus without a way out.
Targets, text size and zoom
Interactive controls are at least 44 pixels on their smallest side. That is the size a thumb hits reliably, and it is well above the 24 pixel minimum WCAG 2.2 introduced at level AA.
Form inputs are set at 16 pixels or larger. Below that, iOS zooms the page when the field takes focus and does not zoom back out, which leaves somebody filling in a form on a viewport they did not choose and cannot easily undo.
Pages reflow rather than scroll sideways down to a 360 pixel viewport, and text can be enlarged without content being cut off or overlapping.
Motion
Only transform and opacity are animated. Nothing animates a large blur or a layout property, because those repaint every frame and turn a scroll into a stutter on a mid range phone, which is an accessibility problem before it is a performance one.
When a visitor's system asks for reduced motion, animation settles to its finished, static, readable state. It does not stop half way and it does not hide the content it was going to reveal. A reveal that respects the setting by never revealing anything is worse than no animation at all.
Colour and contrast
Body text and interface text meet the level AA contrast ratios against the ground they sit on. Crate's primary action colour is the step in the palette chosen specifically because white text passes AA on it, in both the light and the dark theme, rather than the brighter step that looks better and fails.
Colour is never the only carrier of meaning. A status is stated in words as well as in a colour, so somebody who cannot separate two hues still reads the state.
Text alternatives and structure
Decorative artwork is hidden from assistive technology rather than given a description nobody needs. Illustrations that carry meaning are marked as images and described by what the drawing shows. An icon that stands alone as a control carries an accessible name.
Headings run in order and name the section they open, tables carry real header cells, and lists are marked up as lists. That is what makes a page navigable by a screen reader's own heading and landmark shortcuts, which is how most experienced screen reader users move through a page rather than reading it top to bottom.
Fonts and loading
Typefaces are self hosted as woff2 files served from the same origin as the page, so text never depends on a third party font host being reachable and never waits on a request to one.
Images carry explicit dimensions so the page does not shift under a reader's finger as it loads. A layout that jumps is a page that moves the button somebody was about to press.
What we have not done, and what is not ours
A statement that lists only strengths is a statement a reviewer discounts entirely.
-
No independent audit
Nobody outside Crate has tested this. There is no audit report, no VPAT and no certification. Everything here is our own assessment against the published guidelines.
-
No assistive technology matrix
We have not run a documented pass across a named set of screen readers and browsers. Individual problems get tested and fixed; a formal matrix is not in place.
-
Merchant content is the merchant's
Product names, descriptions, alt text and uploaded images are written by the merchant. Crate provides the field and prompts for it, and cannot supply the words.
-
Merchant styling has limits we cannot enforce
A merchant chooses their storefront accent colour. Crate ships readable defaults and derives a readable text colour where it can, but a merchant who overrides both can still produce a pairing that fails contrast.
-
Custom code is unreviewed
A merchant may add their own scripts and markup to their storefront. Anything they add sits outside what Crate builds and outside what Crate can test.
-
Third party screens
A payment provider's own checkout screen follows their accessibility work, not ours. Where one of those screens is the barrier we can raise it with them, and we will say that rather than claim it as ours.
If something on Crate is unusable, tell us
Write to support@crate.shop and describe what you were trying to do, the page you were on, and the browser or assistive technology you were using. None of those are required. One line saying a page does not work is enough to start with.
You get a reply from a person within five working days. It carries either the fix or a date for one, and where the answer is that we cannot change something soon, it says what to do instead in the meantime.
If you would rather use a form than an email address, the contact page reaches the same people.
Contact usQuestions
Short answers, and none of them hedge. If yours is not here, ask us on the contact page.
Which standard does Crate build to?
The Web Content Accessibility Guidelines 2.2 at level AA, applied to the marketing site, the merchant dashboard and every storefront Crate renders. That is the target we build and review against rather than an audited conformance claim, and the difference is stated here rather than blurred.
Has Crate been independently audited?
No. No third party has tested Crate, there is no audit report to send you, and there is no VPAT. If an audit is a hard requirement for your organisation, say so when you contact us and we will tell you honestly where that sits rather than produce a document to close a row.
Does this cover the storefronts my customers see?
Yes for everything Crate renders: the layout, the navigation, the cart, the forms and the checkout flow inside Crate. The words, the photographs and the alt text on a storefront are written by the merchant who runs it, and any custom code they add is theirs as well.
What happens if I report a problem?
A person reads it and replies within five working days. The reply carries either the fix, a date for one, or an explanation of why it is not something we can change, with a workaround where one exists. Reports are not closed by an automated response.
Does Crate work with a screen reader?
It is built to, with landmarks, ordered headings, labelled controls and text alternatives throughout. We have not published a tested matrix of named screen readers and browsers, so the honest answer is that it is built for screen reader use and has not been formally certified for it.
Does Crate respect a reduced motion setting?
Yes. When your system asks for reduced motion, animations settle to their finished static state and content that would have animated in is simply present. Nothing is hidden and nothing is left stranded part way through a transition.
Still have a question?
Every answer above was written by the people who build crate. If yours is not among them, the Help Center goes deeper, and a person reads what you send.
Trust and legal
Every document a security or procurement review asks for, in one place.
Diligence done. Start selling.
Open a store, connect a payment provider and publish. No contract, and no card to start.
14-day free trial · No card required