Website accessibility checker (WCAG)

What the accessibility row looks at

After the page has rendered, the check runs the axe-core rule set against the live document. Each violation is listed with the rule that raised it, how many elements are affected and an example element. A violation of a WCAG A or AA rule makes the row fail; hints that fall outside those levels are reported as best-practice notes.

• Text that does not have enough colour contrast against its background
• Images without a text alternative
• Form fields without a label
• Links and buttons without an accessible name
• A document without a language attribute

Rule ids:a11y_color_contrasta11y_image_alta11y_labela11y_link_namea11y_button_namea11y_html_has_lang

Why it matters

Accessibility is what lets people who use a screen reader, a keyboard, a magnifier or a high-contrast setting actually use your site. In the European Union, the European Accessibility Act extends accessibility requirements to many consumer-facing products and services, and WCAG is the standard most audits measure against. Beyond the legal angle, the same fixes tend to help everyone: readable contrast helps in sunlight, and labelled fields help autofill.

What a fix usually looks like

Most violations repeat across a template, so one fix often clears many findings.

• Raise the contrast of low-contrast text to the WCAG ratio for its size
• Add alt text that says what an image conveys; use an empty alt for purely decorative images
• Connect every form field to a visible label
• Give icon-only buttons and links a name a screen reader can read
• Set the lang attribute on the html element

What automated checking cannot tell you

Automated rules find a part of the problems that exist, not all of them. They cannot judge whether alt text is meaningful, whether the reading order makes sense or whether a custom widget works with a keyboard and a screen reader. A passing result means axe-core found no violations on this page in this state; it is not a certificate of conformance.