A website audit can verify the machine-detectable slice of accessibility: whether images carry alt text, whether text meets a contrast ratio, whether form fields have labels, whether headings nest in order, and whether custom controls expose a valid ARIA role. It cannot verify whether the result actually makes sense to someone using a keyboard or a screen reader, which is a judgment a crawler does not make. Knowing where that line falls is what makes an accessibility check useful instead of a false green light.
What does an automated accessibility check actually catch?
Most of what a crawl can verify has a fixed pass or fail rule, one a machine can apply the same way on every page:
| WCAG check | What it verifies | Automatable |
|---|---|---|
| Image alt text | Every non-decorative image carries a text alternative | Yes |
| Color contrast | Text meets WCAG AA contrast against its background | Yes |
| Form labels | Every input has an associated, visible label | Yes |
| Heading order | H1 through H6 nest without skipping a level | Yes |
| ARIA roles and state | Custom widgets expose a valid role, name and state | Yes |
| Link and button text | Controls read sensibly out of context, not just “click here” | Yes |
| Keyboard reachability | Every interactive element can be reached and operated by keyboard | Partial |
| Reading order | Screen-reader order matches the visual order and actually makes sense | No |
Eight WCAG checks, and which ones a crawl can verify with a fixed rule versus which still need a person.
What still needs a human reviewer?
Confirming that the right markup exists is not the same as confirming that using it makes sense. That gap is exactly where an automated check has to stop and a person has to start.
- Alt text present on every image
- Contrast ratio meets WCAG AA
- Every form field has a label
- Headings nest without skipping a level
- ARIA roles are valid and present
- Alt text actually describes the image
- Tab order matches a sensible reading order
- A screen reader announces state changes correctly
- Error messages are understandable, not just present
- The experience works, not just passes
Why accessibility now sits next to Core Web Vitals
Accessibility used to be treated as a separate compliance track from the rest of a site's technical health. Three things changed that:
- Legal exposure is documented. ADA-related web lawsuits go after exactly the kinds of failures that a crawl can catch, such as missing alt text, forms that have no labels, and contrast that fails at a glance.
- The overlap with SEO and AI Visibility is direct. Alt text, heading structure and descriptive link text are read by search crawlers and AI engines much the way a screen reader reads them, so a fix here helps both.
- Screen-reader and keyboard users are customers. A checkout that a mouse user can finish but a keyboard user cannot is associated with lost conversions. You can test the flow using the keyboard alone, so you can see where it breaks.
What does a missing-alt-text finding look like?
Each accessibility issue is scored the same way as every other finding on the site: an observation, its cost, a fix, and the evidence behind it.
Product images ship with no alt text
How much do accessibility gaps cost the score?
Accessibility findings are not scored on a separate scale. They draw from the same additive pool as every other Experience check, so fixing one shows the same kind of points back as fixing a slow page.
How to check the basics in five minutes
A handful of checks catch a large share of the common failures without any tooling beyond a browser.
- Turn off images and read the page. Anywhere a missing image leaves no clue what it was, the alt text is missing or wrong.
- Tab through the page with no mouse. If focus disappears, skips a control, or gets trapped, that control fails keyboard access.
- Zoom the page to 200%. Text that overlaps or gets clipped signals a layout that was never tested at that size.
- Check the heading outline in devtools. A jump from H1 straight to H4 is a skipped level.
- Run a free Snapshot of the homepage. It reports the machine-detectable failures above alongside the rest of the Experience pillar.
Accessibility audit FAQ
Does an automated check make a site WCAG compliant?
No. It verifies the checks that have a fixed pass or fail rule, alt text, contrast, labels, heading order and valid ARIA among them, but full WCAG conformance also needs a person testing real navigation with a keyboard and a screen reader. Treat an automated pass as a solid floor, not a certificate.
Is accessibility part of SEO?
Not directly, but the overlap is large. Alt text, heading structure and descriptive link text are read in much the same way by a screen reader, a search crawler and an AI engine assembling an answer, so most accessibility fixes also help findability and AI Visibility.
How does Auditaar score accessibility?
As part of the Experience pillar, alongside Core Web Vitals and mobile layout. Each machine-detectable failure is scored like any other finding: an observation, its cost to the A-Score, a fix, and the evidence behind it.
Auditaar checks the machine-detectable half of accessibility, alt text, contrast, labels, heading order and ARIA roles, on every audit depth, and the Deep Dive turns each failure into a fix ranked by what it earns back. Run a free Snapshot, or read how to read a website audit.