Oxwyn Studio

Free tool

What do the automated accessibility checks find?

We run Google Lighthouse's accessibility audit on your page and report what it found, plus whether your images carry alt text and your document declares a language. Read the section directly below first, because what this cannot tell you matters more than what it can.

We read the page, its headers, its certificate and its public DNS records. We do not log in, we do not probe admin paths, and we identify ourselves in your server logs as OxwynXRay.

This cannot tell you whether your site is accessible

It runs a set of automated rules and reports what they flagged. Automated tools detect only a minority of real accessibility barriers, and no automated tool can determine WCAG conformance, because most success criteria require human judgement. A clean result here is not compliance, is not a conformance statement, and should never be shown to a procurement team as evidence of either. What it is genuinely good for is clearing the mechanical faults cheaply before a person spends time on the ones that need a person. If somebody has asked you for an accessibility statement, this is a starting point and not the answer.

Why this matters commercially, not just ethically

In the UK the Equality Act 2010 requires reasonable adjustments for disabled people, and a website providing a service is covered. More immediately for most businesses, accessibility questions now appear in procurement: public sector buyers and larger corporates ask, and being unable to answer costs you the work regardless of whether anybody ever complains.

The things automation reliably catches

Colour contrast below the threshold, images with no alt attribute, form inputs with no label, a document that does not declare its language, buttons with no accessible name. These are real barriers, they are mechanical, and they are the cheapest ones to fix. Clearing them is worth doing and is where most sites should start.

The things it will never catch

Whether alt text actually describes the image or just says photo. Whether the tab order follows the visual order. Whether a modal traps the keyboard. Whether an error message is announced. Whether your content makes sense when read aloud with no visual layout. These are the barriers that actually stop people, and finding them needs a person with a screen reader.

What a real audit looks like

Automated pass first, because it is cheap and clears the noise. Then manual keyboard testing across every flow, screen reader testing on the journeys that matter, and testing with real assistive technology users where the stakes justify it. Anybody selling you WCAG compliance on the strength of an automated scan is selling you a number, not an outcome.

If a buyer has asked you for evidence

What a WCAG conformance claim, audit summary and remediation roadmap actually contain

Questions

Does passing this mean my site is WCAG compliant?
No, and we will not imply otherwise. Automated testing covers a minority of WCAG success criteria. Most require human judgement, such as whether alt text is meaningful or whether a flow can be completed by keyboard alone. A clean automated result and an inaccessible website are entirely compatible.
A client has asked for an accessibility statement. Is this enough?
No. A statement should describe what you have tested, how, what you know is not yet conformant and what you are doing about it. An automated scan is one input. Publishing a statement claiming conformance on the strength of one would be a claim you cannot support.
What should I fix first?
Colour contrast, missing alt text and unlabelled form fields, in that order. They are the most commonly flagged, the cheapest to fix, and between them they remove a real share of the mechanical barriers before anybody spends money on a manual audit.

This tool is one part of the full X-Ray, which measures security headers, your certificate, speed, indexability and what your site publishes about itself. Same scan, same free report.