Most WordPress accessibility failures come from three places: the theme, the page builder, and plugins that inject markup late. Automated testing finds the ones that are decidable from the DOM — missing labels, contrast, heading order, ARIA that references ids that do not exist.
This scan runs axe-core against your live pages in a real browser, so anything rendered by JavaScript is tested as a visitor would receive it.
What this scan checks first
These are the rules that appear most often in filed accessibility complaints. Each links to the fix for WooCommerce.
- Images missing alternative text — 1.1.1 Non-text Content (Level A)
- Links with no discernible text — 2.4.4 Link Purpose (In Context) (Level A)
- Buttons with no accessible name — 4.1.2 Name, Role, Value (Level A)
- Text colour does not contrast enough with its background — 1.4.3 Contrast (Minimum) (Level AA)
- Form inputs with no label — 1.3.1 Info and Relationships (Level A)
- No way to skip repeated navigation — 2.4.1 Bypass Blocks (Level A)
What automated testing cannot tell you
A scan decides what is decidable from the markup. It can prove an image has no alt attribute. It cannot tell you whether the alt text you wrote actually describes the photograph. It can measure contrast; it cannot judge whether your error messages make sense to someone using a screen reader under time pressure.
We say so on every report rather than at the bottom of a terms page, because the opposite claim is what earned a competitor a $1,000,000 FTC order in January 2025.