Accessibility

Where REEVUU actually stands

REEVUU has not had an external accessibility audit, and it has not been tested with people who use screen readers, switch access, voice control or magnification as part of daily life. Until both of those have happened, we are not in a position to tell you REEVUU meets a particular accessibility standard, and we would rather say so than publish a badge we cannot stand behind.

What follows is the specific, checkable work that is in place today.

What is checked before a release

These are automated browser checks, run against the live site in Chromium before a release goes out. They are run deliberately rather than on every commit, so they are a pre-release gate rather than a continuous one.

• Keyboard only. The site header, the homepage and the document carousel are driven with the keyboard alone at desktop and mobile widths, checking that focus is visible and never lands somewhere it cannot leave.
• A skip link and one main landmark. Every page starts with a skip-to-content link, and each page renders exactly one <main>region, so a screen reader is not offered two competing answers to “where does the content start?”.
• Touch targets.Interactive controls are held to a minimum of 44 × 44 pixels, measured in the browser rather than assumed from the stylesheet.
• Text contrast.Contrast ratios are computed from the colours the browser actually rendered, rather than read off the stylesheet, and the site chrome is held above 4.5:1. A full-page contrast sweep of the public pages was also run before launch. Those numbers relate to a threshold WCAG 2.2 defines, but measuring the text we measure is not the same as conforming to the standard, and we are not claiming that we do.
• Reduced motion. With prefers-reduced-motion set, content is present on the first paint and nothing animates.
• Without JavaScript. The public pages paint their key content with JavaScript disabled.

Known gaps, stated plainly

• No independent audit, and no formal conformance statement against WCAG or any other standard.
• No testing with assistive technology users. Automated checks find contrast and structure problems; they do not tell us whether REEVUU is genuinely usable with a screen reader.
• Automated coverage is strongest on the public pages. The signed-in review pages have had less of it.
• A review of a scanned or photographed document depends on the text in the image being readable. Where it is not, REEVUU says so rather than guessing — but the underlying document is still not accessible to you or to us.

If something blocks you

Please email hello@reevuu.co.uk and tell us what you were trying to do, what happened, and what you were using — the browser, and any assistive technology. A screenshot or a short recording helps but is never required.

REEVUU is built by a single founder, so there is no dedicated accessibility team and no response-time commitment we could honestly promise. Reports are read and acted on directly, and anything that stops someone completing a review is treated as a defect rather than a feature request.