Accessibility

The target

This site is built to meet WCAG 2.2 Level AA.

What we do to hold that

Accessibility is enforced by the build rather than reviewed at the end. A change that breaks any of the following does not ship:

• Automated checks on every page. An accessibility test suite runs against every route, at mobile, tablet and desktop widths, in three browser engines. Any violation fails the build.
• Contrast checked as data, not by eye. Every colour in the design system declares which surfaces it may carry text or boundaries on, and a test computes the real ratio for each combination. A colour used somewhere it does not meet the threshold fails the build.
• Keyboard journeys tested. Automated tests walk the site by keyboard, confirming the skip link comes first, focus stays visible, focus order matches reading order, and the mobile menu traps and restores focus correctly.
• Reduced motion honoured. If your system asks for reduced motion, non-essential animation stops.
• Target sizes. Interactive elements meet a 44 by 44 pixel minimum.
• Structure. One h1 per page, no skipped heading levels, real landmarks, real lists, real tables with captions and scoped headers.

Three colours in our original design specification did not meet the contrast their intended use required. Rather than use them anyway, we added alternatives and documented the measurements. That is the kind of thing the automated checks exist to catch.

What we know is not perfect

We would rather list these than let you discover them.

• Automated testing has limits. Automated tools catch a meaningful proportion of issues, not all of them. Things like whether a link’s text makes sense out of context, or whether an error message is genuinely helpful, need a person. We have not yet had an independent audit by testers who use assistive technology daily. That is planned, and until it happens this claim rests on our own testing.
• We have not tested with every screen reader. Our automated tests use accessibility APIs rather than driving real screen readers. Behaviour in a specific screen reader and browser combination may differ from what our tests assert.
• Long-form content depends on how it is written. The templates are accessible; a badly written heading or an unhelpful link label is still possible. We review this, and reviews miss things.
• The data table on some pages scrolls horizontally on narrow screens. It is reachable by keyboard and labelled as a scrollable region, which is correct, but a wide table on a small screen is inherently harder to use than we would like.
• No accessibility statement covers what has not been built. Commerce, account pages and product verification are not on this site yet. When they arrive they will be held to the same standard, and this page will be updated with whatever gaps they carry.

Assessment basis

This statement is based on our own automated and manual testing rather than on an independent third-party audit. We have said so plainly because an accessibility statement that implies external validation it does not have is worse than none.

Tell us if something does not work

If any part of this site is difficult or impossible for you to use, we want to know, and you do not need to explain your situation or use any particular terminology.

Email hello@dropkultxr.com. Include the page and what happened, if you can — but a message saying “the menu does not work with my screen reader” is entirely enough to act on.

We will acknowledge within one business day and tell you what we are going to do about it, including if the answer is that a fix will take a while.

If you need information from this site in a different format, ask and we will send it.

Last reviewed

The effective date above. This page is reviewed when the site changes materially, and updated when a gap is found or closed.