Accessibility statement

What we aim for

This site is intended to conform to Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. We treat that as a floor rather than a target: several things below go further than AA requires, and where we fall short we say so rather than claiming partial conformance and leaving you to find out.

What should work

• Keyboard only. Every link, control and filter is reachable and operable with the keyboard alone, focus is always visible, and a “skip to content” link is the first thing you reach on every page. There are no positive tabindex values anywhere, so the tab order follows the page.
• Reading order matches what you see. On a phone, product results come before the filter panel in the markup as well as on screen.
• No JavaScript required. Filters, sorting links, the category navigation and the expandable answers are ordinary links, native <details> elements and checkboxes, so they work with scripting off or unavailable.
• Screen readers. Prices are announced as amounts (“12 pounds 99”) rather than as a currency glyph, ratings are announced as a sentence as well as drawn as stars, comparison data is in real tables with captions and row headers, and every link that opens a new tab says so.
• Colour is never the only signal. Best values in comparison tables carry a weight change and a hidden label as well as a colour; active filters are a full inversion plus aria-current; stock warnings carry an icon and literal text.
• Zoom and reflow. Pages work at 200% and 400% browser zoom without two-dimensional scrolling, down to a 320 CSS pixel width. Pinch-zoom is never blocked.
• Reduced motion. With “reduce motion” set in your operating system, every movement and scale in the interface collapses to zero and smooth scrolling switches off. Nothing on the site moves, auto-plays or auto-advances by itself in any case.
• Touch targets. Controls are at least 24×24 pixels, and the ones you use most on a phone are 44×44.

How we test

Automated checks catch roughly a third of accessibility problems, so they are the floor and not the whole story. Ours run on every change and block a release when they fail:

• axe-core over five representative page templates of the actual built site — the full WCAG 2.0, 2.1 and 2.2 A and AA rule sets plus axe’s best-practice rules, with no rule exceptions. Zero violations.
• Structural checks over every page we publish (currently more than 1,100): one <main>, no skipped heading levels, a language on every document, the skip link first in the tab order, an accessible name on every form control, a caption and row scopes on every table, alternative text on every image.
• Colour contrast computed from the actual palette in both light and dark themes, including semi-transparent backgrounds, which are the ones people usually forget.
• Real-browser checks for the things only a rendered page can answer: contrast in context, target size, reflow at 320–640 pixels, portrait and landscape, layout stability, and that the skip link and keyboard navigation genuinely work after a page change.

Known problems

We are aware of the following, and they are being worked on.

• Comparison tables scroll sideways on a narrow screen. A specification table keeps its columns and scrolls horizontally inside its own frame rather than reflowing into cards. The data is complete and reachable, but it needs a sideways swipe below roughly 640 pixels of width.
• Category and filter pages scroll sideways below about 640 pixels. A wide comparison table on those pages pushes the whole page rather than only its own frame. This fails WCAG 2.2 success criterion 1.4.10 (Reflow) and is our highest-priority fix.
• The cookie notice covers the sticky price bar on a phone. Until you accept or decline, the bar pinned to the bottom of a product page sits underneath the notice. The “View on Amazon” button in the page body works throughout.
• We have not yet tested with a screen reader or on physical devices. Our screen-reader claims come from the markup and from automated checks of computed roles and names, not from a session with NVDA, JAWS or VoiceOver. That testing is planned, and until it has happened we would rather tell you than imply otherwise.
• Some secondary links are smaller than 44 pixels. The breadcrumb trail and a few in-card links are 24 to 32 pixels tall. They meet the WCAG 2.2 AA minimum but not our own target.

Tell us about a barrier

If something here stops you doing what you came to do, we want to hear about it — including the problems not listed above. Contact us and tell us what you were trying to do, what happened, and which browser or assistive technology you were using. That last detail is usually what makes a report reproducible.

We are a small independent site rather than a public body, so we are not covered by the public sector accessibility regulations. We are covered by the Equality Act 2010, and in any case we would rather fix a barrier than argue about whether we have to.

This statement

Prepared on 10 August 2026. It is based on our own automated and browser-based testing rather than a third-party audit, and it is reviewed whenever those tests change what they can prove.