Check your form for accessibility

What the form checker checks

The checker fetches the page once, runs no JavaScript and examines the HTML of every form on the page. Among other things, it checks:

• Labels: Does every field have an accessible name? Is the placeholder the only label? Does a label point to nothing?
• Groups and required fields: Are radio buttons in a fieldset with a legend? Is the asterisk explained, and is the field marked as required in the code?
• Input purpose: Do fields for name, email, address and telephone have the matching autocomplete value?
• Buttons: Do submit buttons and icon buttons have a name? Are there clickable elements that cannot be reached with the keyboard?
• Error messages: Are fields marked as invalid connected to a message? Are there live regions for status messages?
• CAPTCHA and sign-in: Image CAPTCHAs without an alternative, maths questions, blocked pasting. The checker applies success criterion 3.3.8 only to sign-in forms, because it only covers the steps of signing in.
• Page: Language, page title, headings, positive tabindex, focus outlines removed in the HTML, automatic reloading and zoom blocks.

Anything that cannot be decided reliably without a browser appears in the result as a note, not as an error.

What the checker cannot do

Reading only the source code, the checker sees neither colours nor layout nor anything that JavaScript creates later. So it does not check contrast, the tab order, focus styles from external stylesheets or what a screen reader announces. If your form is only built with JavaScript, for example by an embedded form service, paste the HTML from your browser's developer tools.

Automated checks only ever find some of the barriers. The UK Government Digital Service tried ten automated tools on a test page with 143 deliberate barriers: together they found 71 per cent, and 42 barriers were found by none of them (GOV.UK, 2017 (opens in a new tab)). The W3C also says that tools cannot check everything and that human judgement is required (W3C (opens in a new tab)).

So add manual checks: fill in the form with the keyboard only, and listen to it with a screen reader such as NVDA (opens in a new tab) on Windows or VoiceOver on Apple devices.

The result is not proof of accessibility. It is not a manual audit and not a certificate. It shows you where to start.

The most common errors in forms

In February 2026, the WebAIM Million study automatically checked the home pages of one million websites. Missing form input labels were found on 51 per cent of pages, one third of all form inputs (33.1 per cent) were not properly labelled, and 30.6 per cent of pages had empty buttons (WebAIM Million 2026 (opens in a new tab)). In forms, we see these patterns again and again:

• A placeholder instead of a label: after the first keystroke, nobody can see what belongs in the field.
• Yes and No without the question, because fieldset and legend are missing.
• An asterisk without an explanation and without required in the code.
• Errors shown only in red, with no text at the field.
• Submitting through a div with a click handler instead of a button.
• Icon buttons without a name, such as a magnifying glass or a cross to close something.

There are separate figures for grant application forms. In a measurement by Schwerpunkt on 18 October 2026, 52 of 53 open online application forms from German funders (98 per cent) had at least one finding under WCAG 2.2 A/AA. For 291 of 334 fields for name, email, telephone or address (87 per cent), a valid autocomplete attribute was missing; the form checker tests for this. Text contrast that is too weak was the most common finding of the automated check with axe, at 37 of 53 forms. That is something you check by hand or with another tool.

Moving from paper or PDF forms to online forms? Read our guide Paper and PDF forms to accessible online forms.

The legal framework in the UK

The technical benchmark is WCAG 2.2 (opens in a new tab) from the W3C at Level AA. Public sector bodies must make their websites and mobile apps accessible under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (opens in a new tab). According to the government guidance, this means meeting WCAG 2.2 AA and publishing an accessibility statement (GOV.UK (opens in a new tab)). For these bodies, failing to meet the accessibility requirement is treated as a failure to make a reasonable adjustment under the Equality Act 2010 (regulation 12 (opens in a new tab)).

The guidance also says that charities and other non-government organisations are exempt from these regulations unless they are mostly financed by public funding, or provide services that are essential to the public or aimed at disabled people (GOV.UK (opens in a new tab)).

Separately, the Equality Act 2010 applies in England, Scotland and Wales (section 217 (opens in a new tab)) to anyone who provides a service to the public, for payment or not. Service providers have a duty to make reasonable adjustments for disabled people (section 29 (opens in a new tab)), and for services this duty is owed to disabled people generally (Schedule 2, paragraph 2 (opens in a new tab)). Where the duty relates to information, the reasonable steps include providing the information in an accessible format (section 20 (opens in a new tab)).

The European Accessibility Act (opens in a new tab) covers certain services provided to consumers in the EU, including e-commerce services (Article 2(2)). Microenterprises that provide services are exempt from its accessibility requirements (Article 4(5)). If you sell to consumers in the EU, check whether it applies to you.

Whether a duty applies to your form depends on your organisation and your situation, so take legal advice for your own case. The checker does not give legal advice.

What to do with the result

1. 1Critical findings first: Fields and buttons without a name usually shut screen reader users out completely.
2. 2Keyboard: Put the mouse aside, tab through all the fields and submit the form. Can you always see where the focus is?
3. 3Errors: Fill in the form wrongly on purpose. Does a screen reader such as NVDA (opens in a new tab) or VoiceOver announce the messages?
4. 4Check again: Run the checker again after every change.

If you need a manual check or help with the fixes, see our accessibility audit and fixes. Our demo (opens in a new tab) shows a form before and after, with a built-in checker; its interface is in German.