People with disabilities may struggle to use your page

Applies to

every page

Typical severity

high

Effect on conversions

medium

Effort to fix

Quick to fix

What to look for

Any axe-core violation; each rule becomes its own finding with the affected elements.

Why it matters

Accessibility problems stop real people from using your site. Someone with low vision can't read faint text. Someone using a screen reader can't tell what an unlabelled button does. Someone filling in a form by voice can't find a field with no name. Each of these is a lost enquiry or sale.

In the UK, the Equality Act expects businesses to make reasonable adjustments for disabled people, and that includes websites. The European Accessibility Act now applies to many businesses that sell to customers in the EU. WCAG 2.2 at level AA is the standard both point to.

Automated tools can't find every problem, but they find the common, clear-cut ones quickly and reliably. That makes them the best place to start.

What good looks like

We run axe-core, the open source engine from Deque, against the page with its WCAG 2.2 A and AA rules switched on. That is around 90 rules covering colour contrast, image alt text, form labels, link and button names, page language, landmarks, ARIA use and more. The page passes when axe reports no violations. Each failing rule becomes its own finding, listing the affected elements.

How to check it yourself

1. Install the free axe DevTools extension for Chrome, Edge or Firefox.
2. Open your page, open the browser developer tools (F12 or right-click and choose Inspect) and go to the axe DevTools tab.
3. Click to scan the full page. Each issue lists the rule, why it matters and the elements involved.
4. Click an issue to highlight the element on the page so you can see exactly what is affected.
5. Repeat on your other key pages: home, a product or service page, contact and any forms.
6. Lighthouse (built into Chrome dev tools) runs a subset of the same axe rules under its Accessibility score, if you want a second view.

How to fix it

• Start with the issues axe marks as critical or serious. These usually block people outright.
• Fix the patterns, not just the instances. If one icon button has no name, the same component is probably used elsewhere.
• Colour contrast: body text needs a ratio of at least 4.5:1 against its background, and large text at least 3:1.
• Images: give every meaningful image a short alt description. Purely decorative images get an empty alt.
• Icon-only links and buttons: add an aria-label that says what they do.
• Form fields: give each one a visible label tied to it with for and id.
• Re-scan after each round of fixes to confirm they cleared.

<html lang="en-GB">
<!-- Meaningful image -->
<img src="team.jpg" alt="Our three engineers outside the Leeds workshop">
<!-- Decorative image -->
<img src="swirl.svg" alt="">
<!-- Icon-only button -->
<button aria-label="Open menu"><svg aria-hidden="true">...</svg></button>
<!-- Labelled field -->
<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email">

Common mistakes

• Treating a clean automated scan as proof the site is accessible. Keyboard use, focus order and how clear the content is still need a person to check.
• Using placeholder text instead of a label. It disappears as soon as someone types.
• Adding ARIA attributes to fix things that plain HTML elements already handle. A real button beats a div with a role.
• Fixing issues on one page but not in the shared template, so they come back.

AgoraScan measures this automatically on every page it audits, on desktop and mobile.

Based on

• axe-core (Deque)
• WCAG 2.2 success criterion 2.2 A and AA