Accessibility statement
This statement applies to duneair.com. We want as many people as possible to be able to use this site — including buying from it, which is the part that matters most.
Compliance status
This website is partially compliant with the Web Content Accessibility Guidelines version 2.2 AA standard, because parts of that standard have not yet been independently verified.
We know of no outstanding failures. Every automated check we run passes on every page. But automated testing catches roughly a third of the ways a website can be inaccessible, so “our tests pass” and “this site is accessible” are not the same sentence, and we are not going to write the second one until the checks in the next section have been done. A statement claiming full conformance on the strength of a green automated run is the most common thing on pages like this, and it is not worth much.
- Standard
- WCAG 2.2 AA
- Status
- Partially compliant — parts unverified
- Known failures
- None outstandingEverything found so far has been fixed; the list is in “what the testing found” below.
- Legal basis
- Equality Act 2010We are not a public sector body, so the 2018 accessibility regulations don't apply to us. We publish this anyway.
What you should be able to do
The first four are verified automatically, on every change, and have to pass before anything ships. The last is a design decision rather than something a script can measure — so it is written down here, where breaking it would be visible.
Zoom to 400% without losing anything
Every page reflows into a single column at 320px, which is what a 1280px screen becomes at 400% zoom. Nothing scrolls sideways and nothing is cut off. This is tested automatically on every change.
Use the whole site by keyboard
Every interactive control can be reached and operated with a keyboard, every one shows a visible focus ring, and there are no focus traps. A skip link takes you past the navigation. Tested automatically on every change.
Tap things without missing
Every interactive target is at least 24 by 24 pixels, or has enough space around it to amount to the same thing — WCAG 2.2's target size rule, checked on every route at phone and desktop widths.
Turn the motion off
If your device asks for reduced motion, transitions across the site drop to effectively nothing. Near-zero rather than zero, because a duration of exactly zero makes some browsers skip the event that tells the page an animation has finished.
Get to your order without remembering anything
The order page asks for the email you ordered with and the postcode it's being fitted at — information you already have, never a password, a puzzle or a code to memorise. Paste works, and your browser or password manager can fill both fields. That is WCAG 2.2's accessible authentication rule (3.3.8), and it is the reason this is not a login.
What we haven't checked
The standard section of a statement like this is called “non-accessible content”. We have no known failures to list — so what follows is the honest version: the checks that have not been done, and therefore the places a problem could still be hiding.
Not yet verified
- A screen reader pass. Nobody has been through the quote flow or the checkout with VoiceOver or NVDA — the two places where getting it wrong costs you money rather than patience
- Text-only resize to 200% (WCAG 1.4.4), which is a browser setting no script can emulate
- Contrast in hover, focus, disabled and error states. The base palette was checked properly; the states were not
- Whether the tab order makes sense, as opposed to merely being unbroken — which is all a script can tell us
- Whether a form error is announced when a field is rejected (WCAG 3.3.1)
- Three WCAG 2.2 criteria no tool can check: dragging movements (2.5.7), consistent help (3.2.6) and redundant entry (3.3.7). We believe we meet all three; nobody has confirmed it
Known limits
- Nobody with a disability has tested this site. That is the gap that matters most, and it is not one we can close by writing more tests
- We have no accessibility certification and are not seeking one — a badge is not the same as a working page
- There is no phone line as an alternative route. That is a deliberate decision made for other reasons, and it is a real accessibility cost we are choosing to carry
Tell us when something doesn't work
If any part of this site stops you getting a price, asking a question or completing a purchase, that is our problem and not yours.
Email us through the contact form and say what you were trying to do. We answer within one working day, the same as any other enquiry — and we will complete the order or the quote with you directly rather than asking you to fight the website while we fix it.
It helps if you can tell us the page, what you were using (browser, phone, screen reader) and what happened. It is genuinely useful even if you are not stuck and just noticed something wrong. If you need anything on this site in another format, ask and we will send it.
If you contact us about an accessibility problem and you are not happy with how we respond, the Equality Advisory and Support Service (EASS) gives free advice on rights under the Equality Act 2010.
How we tested this
Prepared by the team that builds the site, using the tooling described below rather than a one-off audit somebody commissioned and filed.
Three things run on every change and have to pass before anything ships. axe checks every route against WCAG 2.2 A and AA at desktop and phone widths, including the pages behind a purchase, and opens every tab panel — because content that breaks only once its tab is selected is exactly what a static scan misses. The same check runs against every component in isolation, which catches different things: one sees a heading out of order, the other sees a button with no accessible name.
A third pass covers what axe cannot. It tabs through every page looking for focus traps and controls you can focus but not see, measures every interactive target, tests reflow at 320px, and checks that the floating header never completely covers whatever you have just tabbed to — WCAG 2.2’s focus not obscured rule, which exists for headers exactly like ours.
What that testing found. Every link in the footer was too small to tap: 18 pixels tall against a 24-pixel minimum, on every page of the site, which is what a shared component does when it is wrong. The same problem turned up on the guide contents rail, a product breadcrumb, a checkbox, and a link in the checkout form that was 20 pixels tall.
One of our own brand colours failed on contrast at 3.43:1 and was replaced rather than granted an exception. Three pages had headings that skipped a level, which reads to a screen reader as a missing section. A closing panel rendered a near-black button on a near-black background.
The tooling was wrong before the site was. The first run of our keyboard checker reported 84 problems and almost all of them were its own fault — it measured the skip link while it was still hidden, and measured hidden radio inputs rather than the large labels wrapping them. We fixed the checker first. A checker that cries wolf gets switched off, and then nothing is being tested at all.
- Standard tested against
- WCAG 2.2 AA
- Method
- Automated, on every changeaxe-core against every route and every component, plus our own keyboard, focus, target-size, reflow and focus-not-obscured checks.
- Tested by
- Duneair, in-houseNot independently audited. That is a gap and it is listed as one.
- Statement prepared
- 18 August 2026
- Last reviewed
- 18 August 2026Updated when the testing changes, not on a schedule.
Everything else we've decided
The same reasoning, applied to the parts of the business that aren't a website — including the things we haven't done yet.