Mobile and accessibility quick audit

How to use it

1. 1Enter the address you want to checkType or paste it into the field marked "Address to check", including the https:// at the front. Use a page real people interact with — a form, a checkout, a signup.
2. 2Press Check and wait a few secondsThe request runs from our server rather than from your browser, so your cache, your extensions and your login session cannot affect the answer. That is the point of it: you are seeing what an anonymous visitor sees.
3. 3Check whether zoom is blockedA viewport tag with user-scalable=no or a small maximum-scale stops people pinching to zoom. It fails WCAG 1.4.4 and it is invisible to anyone who does not need it, which is why it survives on so many sites.
4. 4Fix unlabelled controlsAn input with no associated label is an input a screen reader announces as nothing. Placeholder text is not a label — it disappears the moment somebody types.
5. 5Look at links and buttons with no accessible nameAn icon-only link with no aria-label or alt text is announced as its URL. The tool checks alt, then aria-label, then title, so a name by any route counts.
6. 6Do not read a clean result as a WCAG auditContrast, tap-target size and focus order need a rendering engine and, honestly, a person. The tool says so with the result rather than letting a green pass imply more than it checked.
7. 7Share or keep the result within 24 hoursThe result has its own link you can send to whoever needs to act on it. It is deleted 24 hours after the check ran, so save anything you need to keep — and re-run the check after a change rather than trusting an old link.

About this tool

Most accessibility failures that exclude real users are visible in the markup: a viewport that disables zoom, a missing lang attribute, images without alt text, form fields with no label, icon links a screen reader can only announce as "link". None of them produce errors, all of them turn actual visitors away, and search engines read several of them as quality signals.

This tool audits exactly those — the checks that raw HTML can prove — and reports each finding with the count, examples you can locate in your source, and what a user actually experiences at that gap.

Understanding the result

Critical findings exclude someone outright: no viewport (unreadable on phones), zoom blocked (a WCAG failure — people with low vision zoom to read), unlabelled form fields (a screen-reader user is told nothing about what belongs in them).

Warnings degrade the experience: missing alt text, unnamed links, a missing or malformed lang attribute.

Advisories are structural: no h1, skipped heading levels, missing landmarks, no skip link. Each one makes assisted navigation slower rather than impossible.

alt="" is reported separately as decorative — it is the correct way to mark an image screen readers should skip, and counting it as "missing" would send people to write alt text for flourishes.

Example

https://example.com/checkout

Viewport present, blocks zoom — CRITICAL (WCAG 1.4.4)
3 of 5 form controls unlabelled — CRITICAL: <input type="text" name="card">…
12 images, 4 without alt · 2 icon links unnamed
Landmarks: <main> ✓ <nav> ✓ · no skip link

Limitations

• This is the markup half of an accessibility audit. Contrast ratios, tap-target sizes, focus order and keyboard traps depend on computed style and runtime behaviour — they need a rendering engine and are not judged here. A clean result is not a full WCAG certification.
• Markup is read as served. Labels or ARIA attributes added by JavaScript after load are real to browsers but invisible here.
• The skip-link check is a heuristic — an early same-page anchor — and is reported as an observation, not a rule.
• Requests to private and internal addresses are refused by design.

Questions