Valenys Accessibility Audit
WCAG 2.2 levels A, AA and AAA, checked with static HTML analysis, a real Chromium browser driven by Playwright, and axe-core 4.8.
A full manual evaluation is expensive and slow. With nothing at all, the decision gets made on a guess. The audit sits between the two: days instead of months, and a document you can put in front of a board or an auditor.
Static analysis of the HTML catches what is missing in the markup. A real Chromium browser, driven by Playwright, catches what only exists after the page has loaded and scripts have run — which is where most modern interfaces actually live. And axe-core 4.8, vendored locally rather than fetched from a CDN, covers the rule set the whole industry benchmarks against.
Written specifically to cover what axe-core does not. Thirty-five work on the static HTML; forty-five need the live browser. Among them is a full keyboard walk of the page, pressing tab until the end, which is the only reliable way to find a focus trap — the failure that makes a page unusable for a keyboard user while looking perfectly normal to everyone else.
The engine keeps a registry of 182 distinct checks and maps each one onto the WCAG criterion, level and principle it belongs to. You choose the target level; anything above it is reported as information rather than as failure.
From PageSpeed Insights and the Chrome User Experience Report, where an API key is available — real Core Web Vitals at the 75th percentile, alongside the Lighthouse score. Plus legal observations depending on whether the site is operated by a private company or a public body.
What comes back
Which element, on which page, at which measured ratio - and, next to the failures, the two states a free scanner does not have: what could not be run, and what needs a person to judge.
Every check returns one of: passed, failed, warning, needs human review, could not run, not applicable.
“Could not run” never silently becomes “passed.” That sounds like a small implementation detail. It is the whole difference between a report that flatters you and a report that survives a conformity discussion — because a tool that quietly converts its own failures into passes will report a clean site that is not clean.
The same logic applies to “needs human review”. Criteria that depend on meaning and context cannot be resolved by code, and the report marks them as open questions instead of guessing.
The report carries a numeric index, and the formula that produced it is published. It weights severity, the WCAG level of the criterion, and how many pages are affected. You can recalculate it yourself.
That matters because the market is full of compliance percentages nobody can explain. A score you cannot reproduce is a marketing number, and a board is right to distrust it.
Recommendations, legal observations, performance data and inconclusive results are excluded from the index. Only detected WCAG failures within the target level count.
A structured PDF report of thirteen sections, with concrete instances for each issue — not “contrast problems exist” but which element, on which page, at which measured ratio. Alongside it: a per-page view, the legal framing for your situation, and — from the second run onward — a comparison against the previous audit: what was resolved, what is new, what persists.
It does not replace a manual evaluation conducted by an accessibility specialist, and it does not constitute a formal conformity assessment. The report states this on its first page, before any number. Automated testing reliably detects a portion of the criteria. The rest need a person. Any tool that claims otherwise is selling you a number, not a diagnosis.
If you are still working out what the law requires of you, read the European Accessibility Act page first.
A free scanner checks one page, from one angle, and gives you a screen you cannot hand to anyone. This covers multiple pages and journeys, combines three methods, marks the criteria that need human judgment instead of guessing, and produces a document that holds up in a conformity discussion.
Enough to cover your main user journeys rather than every URL you own. Homepage, a category and a product or service page, the forms, the checkout or contact flow, and the account area. Scope is agreed before we start.
Journey scans with an authenticated real browser can cover flows that require a login. That is agreed during scoping, because it needs credentials and a controlled environment.
It reports each issue with concrete instances and the criterion it fails, which is what a developer needs to act. Remediation itself — and a plan staged over 30, 60 and 90 days — is part of the accessibility platform.
Yes, and you should. From the second run, the report compares against the previous one and shows what was resolved, what is new and what persists.
Compliance documents are generated in seven languages: English, Romanian, German, French, Spanish, Italian and Portuguese. That includes the accessibility statement and the VPAT / Accessibility Conformance Report.
Against WCAG 2.2, which is what EN 301 549 — the European harmonised standard — builds on. The report maps every finding to a WCAG success criterion, which is the level procurement teams and auditors actually work at.
