WCAG 2.2 Level AA · human-reviewed
A person uses your site with a keyboard and with a screen reader, alongside the automated analysis. You get the barriers ordered by what they cost, with the evidence and how to fix them.
The work
Two halves that complete each other: what the source reveals on its own, and what only appears when someone uses the page.
The page is fetched and checked for what the source reveals on its own: alternative text, document language, heading structure, form labels, accessible names, link purpose, target size, and contrast wherever it can be computed.
This is the half no scanner performs. The primary task is completed without a mouse; every control is reached by keyboard while checking focus order, focus visibility and traps; forms are submitted wrong on purpose to see whether the error is announced; and the page is worked through with a screen reader to hear what it actually says. Of the 37 checks in the method, 19 can only be decided by a person.
The standard
WCAG 2.2 Level AA, organised by its four principles. Every finding is mapped to one of them and to its specific criterion.
Whether the information on the page reaches someone who cannot see it, cannot see it well, or cannot distinguish the colours it is drawn in. Content that exists only as a picture, a colour or a contrast too faint to resolve is content that some of your customers do not have.
Whether the page can be used without a mouse. Keyboard access is the principle most often broken by modern component libraries, and the one automated tooling is worst at detecting — a custom dropdown that traps focus passes every scanner and fails every keyboard user.
Whether the page behaves predictably and tells people how to recover. Most of the cost here lands in forms: an error that is announced only in red, a field whose label disappears once it is filled, a session that expires without warning during a checkout.
Whether assistive technology can tell what each control is, what state it is in, and when something on the page has changed. This is where custom components fail: a div styled as a button is a button to everyone except the person who cannot see it.
The deliverable
This is how every barrier arrives in the report: what happens, who it affects, how to fix it and how to confirm it is fixed.
Read a sample reportExample
Scope
Three scopes at a fixed price. No discovery call, no custom quote.
Free$490 after the beta
one page
Free$990 after the beta
one journey, up to 5 pages
Free$2,400 after the beta
representative sample, up to 15 pages
Optional, in the same order.
Coming soon · $390
Title, severity, the success criterion, the affected location, the problem, the evidence, the expected behaviour, a recommended implementation and the acceptance criteria that close it. Delivered as structured text you can paste into Jira, Linear or GitHub.
Coming soon · $190
Immediate priorities, a 30/60/90-day sequence, the technical debt behind the recurring failures, and recommendations on ownership and process so the same findings do not return next quarter.
Coming soon · $190
Scope, the standard assessed against, known limitations, the feedback mechanism and the preparation date — written from your findings rather than from a template. This is a draft for your review and your legal counsel. It is not a certification and Uxerfy does not present it as one.
Coming soon · $290
Run it within 90 days of the original report. You get an updated score, a verification result per finding, and any regression the fixes introduced. It states what was verified on that date — accessibility is a property of a site that changes with every deploy, so nothing here implies a permanent result.
Honesty
Regulatory requirements vary by jurisdiction, service, organisation and other factors. Uxerfy provides accessibility assessments and compliance-oriented information, not legal advice or legal certification. Consult qualified legal counsel for a determination of your obligations.
It does not certify conformance. Uxerfy issues no certifications and gives no legal advice.
It does not establish permanent compliance: it reports the state of the audited scope on the date it was audited. Every deploy can change that.
It does not replace usability testing with disabled users, which answers a different question: whether people actually succeed.
It does not cover native mobile apps or PDF documents unless they are explicitly included in the scope.
Questions
An assessment of a website against a technical accessibility standard — here, WCAG 2.2 Level AA — identifying the barriers that prevent or hinder use by people with disabilities, and documenting what needs to change. At Uxerfy it combines automated analysis with manual keyboard and screen reader testing.
The audit says what fails, why it matters and what behaviour is expected. Remediation is the work of changing the code. Uxerfy audits and supplies the remediation guidance; with the Remediation Pack add-on, each finding arrives as a development-ready ticket with acceptance criteria.
No. The audit is carried out against the published site, the way anyone uses it. Access is only needed when part of the scope sits behind a login or in a test environment, and it is requested after payment.
A staging environment can be audited. Say so on the order and share access when asked; the report records which environment was assessed.
The report documents the scope, the standard, the date and the findings, which is the usual starting material. If the questionnaire requires a signed declaration of conformance from an accredited body, that is a different thing and Uxerfy does not issue it.
Start with your highest-traffic page or your checkout. That is where a barrier costs the most.
Sergio Gualda · Barcelona, Spain