WCAG Checker

How the WCAG Checker works

WCAG checker: what it can and cannot check

About a third of WCAG can be checked by a machine reading the HTML. This tool does that third, thoroughly and locally, and is honest that the other two thirds — is the alt text actually accurate, does the page make sense when zoomed, can every task be completed by keyboard — still need a person. Use it as the first pass that clears out the mechanical faults so the manual review can concentrate on judgement.

Images (1.1.1). Every img needs an alt attribute. A missing one is an error: the screen reader will read the file name instead. alt="" is correct for decorative images and passes. Alt text that is just image, photo or logo fails because it describes nothing; text that looks like a file name fails for the same reason; text starting "image of" gets a notice because the screen reader already says "image". Image buttons and image-map areas need alt text too.

Form fields (1.3.1, 4.1.2). Every text input, select and textarea must have a label that assistive technology can associate with it: a label for= pointing at its id, a wrapping label, or aria-label, aria-labelledby or title. A placeholder is not a label — it vanishes as soon as the user types and is frequently too faint to read — so a field with only a placeholder is reported. Fieldsets without a legend are flagged because the group has no name.

Links and buttons (2.4.4, 4.1.2, 2.1.1). A button with nothing in it and no aria-label reads as "button" and nothing else. A link whose only content is an image with empty alt is announced as its URL. Link text of "click here", "read more" or "here" is flagged because screen reader users navigate by pulling up a list of links, and a list of "read more" is useless. A link with no href is not focusable by keyboard, and href="javascript:…" is a button in disguise. A div or span with an onclick and no role and tabindex is unreachable by keyboard entirely.

Structure (1.3.1, 2.4.2, 2.4.6, 3.1.1). When a full document is pasted, the html element must carry a valid lang, there must be a title, and there should be an h1 and a main landmark. Heading levels should not skip — an h1 followed by an h3 breaks the outline that screen reader users navigate by. Empty headings are errors. Data tables need th cells and ideally a caption. Duplicate ids are errors because label for and every aria-* reference depend on ids being unique.

Focus and keyboard (2.4.3, 2.4.7, 2.1.1). A positive tabindex reorders the tab sequence away from the reading order and is nearly always a mistake. Inline outline: none hides the focus ring so keyboard users cannot see where they are. aria-hidden="true" wrapped around a button or link produces a control that is in the tab order but silent. accesskey gets a notice because it collides with assistive technology shortcuts.

Motion, media and zoom (1.4.4, 1.4.2, 1.2.2, 2.2.2). A viewport meta with user-scalable=no or a maximum-scale under 2 stops low-vision users from zooming and is an outright failure. Media that autoplays with sound and no controls fails; a video with no track element is noted because captions are required for pre-recorded video. marquee and blink fail because they move and cannot be paused.

What it cannot check. Colour contrast needs the computed styles — use the contrast checker with your actual colours. Whether alt text is truthful, whether focus order makes sense, whether error messages are helpful, whether the page works at 400% zoom, whether custom widgets respond to arrow keys: all of these need a human and, ideally, a screen reader. A clean result here means the mechanical faults are gone, not that the page is accessible.

Related tools