AllyScan

What we check

Every check below runs against your page's HTML and maps to a specific WCAG 2.2 success criterion. We publish the full list because a scanner that will not tell you what it tests cannot be evaluated.

19 automated checks

  1. Page language is not declared

    serious

    Screen readers pick a pronunciation voice from the page language. Without it, an English page may be read aloud with e.g. German phonetics, making it unintelligible.

    Fix: Add a valid language code to the root element, e.g. <html lang="en">.

    WCAG 3.1.1 Language of Page (Level A) · EN 301 549 §9.3.1.1

  2. Page has no title

    serious

    The title is the first thing a screen reader announces and the primary way users tell tabs and browser history entries apart.

    Fix: Add a unique, descriptive <title> in the <head>.

    WCAG 2.4.2 Page Titled (Level A) · EN 301 549 §9.2.4.2

  3. Images are missing alternative text

    critical

    Blind and low-vision users receive nothing in place of the image. If the image carries meaning — a product photo, a chart, a logo — that meaning is simply lost.

    Fix: Add alt text describing the image's purpose. For purely decorative images use alt="" so assistive tech skips them.

    WCAG 1.1.1 Non-text Content (Level A) · EN 301 549 §9.1.1.1

  4. Form fields have no label

    critical

    A screen reader announces an unlabelled field as just "edit text". Users cannot tell whether it wants their email, their postcode, or their card number — which is where checkout abandonment comes from.

    Fix: Associate a <label for="…"> with each field, or give the field an aria-label. A placeholder is not a label — it disappears as soon as the user types.

    WCAG 1.3.1 Info and Relationships (Level A) · WCAG 3.3.2 Labels or Instructions (Level A) · WCAG 4.1.2 Name, Role, Value (Level A) · EN 301 549 §9.3.3.2

  5. Buttons have no accessible name

    critical

    Icon-only buttons with no text are announced as just "button". Keyboard and screen reader users cannot tell what will happen if they activate it.

    Fix: Add visible text, or an aria-label (e.g. <button aria-label="Close dialog">), or a <title> inside the SVG icon.

    WCAG 4.1.2 Name, Role, Value (Level A) · EN 301 549 §9.4.1.2

  6. Links have no accessible name

    serious

    An empty link is announced as just "link", with no indication of where it goes. Screen reader users often navigate by pulling up a list of every link on the page — empty entries make that list useless.

    Fix: Give the link visible text, or an aria-label describing its destination.

    WCAG 2.4.4 Link Purpose (In Context) (Level A) · WCAG 4.1.2 Name, Role, Value (Level A) · EN 301 549 §9.2.4.4

  7. Link text is vague ("click here", "read more")

    moderate

    Screen reader users frequently navigate by listing all links on a page. A list of twelve identical "Read more" entries conveys nothing about where any of them lead.

    Fix: Make the link text describe the destination — "Read our returns policy" rather than "Read more".

    WCAG 2.4.4 Link Purpose (In Context) (Level A) · EN 301 549 §9.2.4.4

  8. Pinch-to-zoom is disabled

    serious

    Blocking zoom stops low-vision users enlarging text on a phone. This is one of the most common and most easily fixed mobile accessibility failures.

    Fix: Remove user-scalable=no and any maximum-scale below 2 from the viewport meta tag.

    WCAG 1.4.4 Resize Text (Level AA) · WCAG 1.4.10 Reflow (Level AA) · EN 301 549 §9.1.4.4

  9. Heading levels skip a rank

    moderate

    Screen reader users navigate long pages by jumping between headings. A jump from <h2> straight to <h4> reads as a missing section and makes the page structure misleading.

    Fix: Use heading levels in sequence. Style them with CSS rather than picking a level by how big it looks.

    WCAG 1.3.1 Info and Relationships (Level A) · EN 301 549 §9.1.3.1

  10. Page has no level-1 heading

    moderate

    The <h1> is the page's headline and a primary landmark for screen reader navigation. Without one, users have no reliable anchor for what the page is about.

    Fix: Add exactly one <h1> that describes the page's main topic.

    WCAG 1.3.1 Info and Relationships (Level A) · EN 301 549 §9.1.3.1

  11. Headings are empty

    minor

    An empty heading is still announced as a heading, creating a confusing dead entry in the page outline that screen reader users must skip past.

    Fix: Give the heading text content, or remove the element if it exists only for styling.

    WCAG 1.3.1 Info and Relationships (Level A)

  12. Embedded frames have no title

    serious

    Screen readers announce iframes by their title. Untitled embeds — maps, videos, payment forms — are announced as just "frame", giving no clue what they contain.

    Fix: Add a descriptive title, e.g. <iframe title="Checkout payment form">.

    WCAG 4.1.2 Name, Role, Value (Level A) · EN 301 549 §9.4.1.2

  13. Duplicate id attributes

    moderate

    Labels, ARIA references and skip links all resolve by id. When an id appears twice, assistive technology follows the wrong one and announces the wrong information.

    Fix: Make every id on the page unique.

    WCAG 4.1.2 Name, Role, Value (Level A)

  14. Positive tabindex overrides keyboard order

    moderate

    A positive tabindex forces an element to the front of the tab sequence, so keyboard focus jumps around the page in an order that does not match what the user sees.

    Fix: Use tabindex="0" to make an element focusable, or -1 to remove it, and let DOM order define the sequence.

    WCAG 2.4.3 Focus Order (Level A) · EN 301 549 §9.2.4.3

  15. Page auto-refreshes or redirects on a timer

    serious

    A timed refresh can move users somewhere else mid-task with no warning. People using screen readers or who read slowly may never finish the page.

    Fix: Remove the meta refresh. If a redirect is needed, do it server-side with a 301/302.

    WCAG 2.2.1 Timing Adjustable (Level A) · WCAG 3.2.5 Change on Request (Level AAA)

  16. Audio or video plays automatically

    serious

    Autoplaying sound competes with a screen reader's speech, and can make a page completely unusable until the user finds a way to stop it.

    Fix: Remove autoplay, or mute by default and give a clear, keyboard-reachable pause control.

    WCAG 1.4.2 Audio Control (Level A) · EN 301 549 §9.1.4.2

  17. Data tables have no header cells

    serious

    Without <th>, a screen reader reads a table as a flat run of numbers with no context, so users cannot tell which column or row any value belongs to.

    Fix: Mark header cells as <th> and set scope="col" or scope="row".

    WCAG 1.3.1 Info and Relationships (Level A) · EN 301 549 §9.1.3.1

  18. No skip link to the main content

    moderate

    Keyboard users must tab through every header and navigation link on every page before reaching the content. A skip link turns that into a single keystroke.

    Fix: Add a "Skip to main content" link as the first focusable element, targeting your <main> element.

    WCAG 2.4.1 Bypass Blocks (Level A) · EN 301 549 §9.2.4.1

  19. No main landmark

    moderate

    Screen reader users jump straight to the <main> landmark to bypass navigation. Without it they have to hunt through the page to find where the content starts.

    Fix: Wrap the primary content of the page in a single <main> element.

    WCAG 1.3.1 Info and Relationships (Level A) · EN 301 549 §9.1.3.1

What we cannot check automatically

These require rendering the page in a real browser or testing it by hand. Any tool claiming to check them from HTML alone is guessing.

Why no tool can certify compliance

The UK Government Digital Service tested 13 accessibility tools against 142 deliberately introduced barriers. The best tool found 40%. Deque's own research puts automated coverage at 57% of issue instances — a higher number because a few very common issue types dominate the count — but only around a third of distinct barrier types.

This is why we report findings rather than verdicts, and why we will never put the word “compliant” on a scan result.