What we test
We load your page in a real Chrome browser and run three independent open-source engines on it: axe-core by Deque (MPL-2.0) at a desktop and a phone width, IBM Equal Access (accessibility-checker-engine, Apache-2.0) with its WCAG 2.2 policy, and HTML_CodeSniffer by Squiz (BSD-3-Clause), the engine behind Pa11y, with the WCAG 2 AA standard. Each engine has its own rules and blind spots, so we merge their findings by WCAG success criterion and show which engines flagged each one.
A finding is marked confirmed when axe-core reports a definite violation or at least two engines agree; a possible problem reported by only one engine is marked needs review and counts as a warning, never a failure. We also run the accessibility category of Google Lighthouse. Each criterion lists its level (A or AA), the number of issues and the first affected elements.
- Colour contrast between text and background.
- Alternative text on images and accessible names on buttons and links.
- Labels on form fields such as contact and appointment forms.
- Heading order, landmark regions and list structure.
- The lang attribute, so screen readers pronounce your content correctly.
- ARIA attributes used incorrectly, and elements that cannot be reached by keyboard.
Why accessibility matters for firms in Europe
Accessibility is about real people: clients with low vision, older clients who enlarge text, people who navigate by keyboard or use a screen reader, and anyone reading your site on a phone in bright sunlight. If they cannot read your fees, use your contact form or find your address, they cannot become clients.
It is also increasingly a legal matter. The European Accessibility Act applies from 28 June 2025 to a range of consumer-facing products and services, and the harmonised standard EN 301 549 refers to WCAG 2.1 level AA. Whether and how it applies to a particular firm depends on the services offered and on national implementation, and microenterprises have specific exemptions — but building to WCAG AA is good practice either way.
Limits of automated testing
Automated tools can reliably find a meaningful share of accessibility issues, such as missing labels and low contrast, but not all of them. They cannot tell whether alt text is actually meaningful, whether the reading order makes sense or whether a process can be completed with a keyboard alone. Use this report to fix the obvious problems quickly, then test key journeys by hand — for example, tab through your contact form and try your site with a screen reader.
Quick wins
Most failures on firm websites come from the theme, so fixing one template often fixes every page at once. Darken light-grey body text, give icon-only buttons a text label, connect every form field to a visible label, keep one H1 per page and set the correct lang attribute for each language version. Then rerun the check to confirm the issues are gone.