Formulaires en ligne accessibles : comment concevoir des éléments de formulaire que tout le monde peut utiliser

Why forms decide who can take part online

Ordering a product, booking an appointment, applying for a job or using a government service: almost every important step online ends in one of many web forms. For many people, filling one in takes a minute. For others, the same form is where the process stops.

People who use assistive technologies such as screen readers, Braille displays or voice recognition software often meet barriers that are invisible to everyone else. So do people with low vision, colour blindness or cognitive disabilities. The same applies to many older people and to anyone with a temporary impairment. A missing label, an error message that only says "Invalid input" or a CAPTCHA that requires recognising blurry images is enough to lock them out.

The good news: most of these barriers are easy to avoid, and removing them improves the user experience for everyone. This article shows the most common obstacles first and then explains, element by element, how to build forms that everyone can complete independently.

When online forms become an obstacle

These five barriers come up again and again in accessibility audits. Each one is covered in more detail further down.

• Missing structure and labels: Screen reader users and people with low vision or cognitive impairments cannot tell which field expects what. Visible labels linked to each field, a logical order and grouped sections help.

• Mouse-only operation: People with motor impairments and keyboard or voice control users are locked out. Full keyboard operability and accessible names that match the visible label help.

• Low contrast and small text: People with low vision, older users and anyone on a phone in sunlight struggle to read the form. At least 4.5:1 contrast for text and layouts that still work when text is enlarged to 200% help.

• Complicated CAPTCHAs and time limits: People with cognitive impairments or learning difficulties and blind users often cannot pass them. No puzzles, no time pressure and alternatives such as passkeys or email links help.

• Video or audio without alternatives: Deaf and hard of hearing people and blind users miss the information. Captions, transcripts and text instructions help.

Form elements and their labels

Most forms are built from the same few HTML form controls: text boxes, multi-line text areas, drop-down menus, radio buttons, checkboxes and buttons to submit or cancel.

Every one of these form fields needs an accessible name. Screen readers announce this name when the field receives focus, so users know what to enter. The most reliable way to provide it is a visible label element that is linked to its field: the for attribute of the label matches the id of the field. This programmatic association is what turns visible form labels into information that assistive technologies can use.

<label for="first-name">First name</label>
<input type="text" id="first-name" name="first-name" autocomplete="given-name">

<input type="checkbox" id="newsletter" name="newsletter">
<label for="newsletter">Send me the newsletter</label>

For text fields and selection lists, place the label before the field. For checkboxes and radio buttons, place it after. A linked label has a second benefit: clicking it also activates the field, which gives people with motor impairments a larger target.

Related radio buttons or checkboxes belong in a fieldset with a legend. The legend works as a group-level visible label: it names the group, and screen readers read it together with each option.

<fieldset>
  <legend>Preferred contact method</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">Email</label>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>

Use WAI-ARIA attributes only where native HTML markup is not enough. The ARIA attribute aria-labelledby can point to existing visible text, and aria-label gives a name to a control without visible text, such as an icon button. Make sure the accessible name contains the visible label word for word. Otherwise voice control users who say "click Send" will not reach the button.

Single-line and multi-line input fields

Single-line fields (input) suit short data such as a name or an email address. Choose the matching type, for example email or tel. On mobile devices this opens the right keyboard. Multi-line fields (textarea) suit longer messages.

html

<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">

<label for="message">Your message</label>
<textarea id="message" name="message" rows="5"></textarea>

The autocomplete attribute lets browsers fill in known personal data. This saves typing and helps people with motor or memory impairments (WCAG 1.3.5).

Placeholders do not replace labels

A placeholder can show an example of the expected format, such as "DD/MM/YYYY". It must never be the only label. Placeholder text disappears as soon as someone starts typing, so users lose the information they need to check their entry. It is also usually light grey and does not meet the minimum contrast. Put format hints in the label or in a hint text below the field instead, and link that text with aria-describedby.

Mandatory fields

Mark required fields clearly and explain the marking at the start of the form, for example "Fields marked with * are required". Do not rely on visual cues such as colour alone, as people with colour blindness will miss them. Add the required attribute, or the aria-required attribute for custom controls, so that screen readers announce the field as required.

Keyboard, mouse and voice: every input method must work

Not everyone uses a mouse. People with motor impairments often rely on the keyboard, a switch device or voice control. Blind users navigate with the keyboard and a screen reader. A form must therefore support keyboard navigation and be fully operable without a mouse:

• Every field, option and button can be reached with the Tab key, in a logical order that follows the visual layout.

• The focus is always clearly visible, for example through a strong outline.

• Custom elements such as styled dropdowns or date pickers work with the arrow keys, Enter and Space, just like native elements.

• No keyboard trap: users can always move on from a field.

• Click and touch targets are large enough, at least 24 by 24 pixels (WCAG 2.5.8). This matters for touch interaction on phones and for people with tremors.

Avoid single-key shortcuts and the accesskey attribute. They often clash with shortcuts of screen readers, browsers and voice control software. If you do offer shortcuts, users must be able to switch them off or change them (WCAG 2.1.4).

Contrast and text size

Text and labels need a contrast ratio of at least 4.5:1 to their background. Field borders, focus indicators and icons that are needed to understand the form need at least 3:1. A colour contrast checker shows quickly whether your colours meet these values. Use a readable font size and make sure the form still works when users enlarge text to 200% or zoom in: nothing overlaps, nothing is cut off, and no horizontal scrolling is needed on a narrow screen.

A clear form layout helps too. Group related fields, separate logical sections visually and keep the layout predictable, so that people with cognitive impairments can follow the form step by step.

Help and error messages

Good forms prevent errors before they happen. Offer short help text next to the field, a tooltip or a link to a help page wherever the expected input is not obvious.

HTML5 validation attributes such as required, type="email" or pattern catch many mistakes automatically. The default error bubbles of browsers are not reliably accessible, though, so add your own error messages as well.

When an error does occur, the message must say exactly what went wrong and how to fix it. WCAG calls this error identification and error suggestion (WCAG 3.3.1 and 3.3.3). Show it in text next to the affected field, not only through a red border, and link it to the field with aria-describedby. On submit, move the focus to the first faulty field or to an error summary at the top of the form.

Some examples of unhelpful and helpful messages:

• Format error: Instead of "Invalid input", write "Enter the date as DD/MM/YYYY, for example 05/03/2026".

• Value error: Instead of "Invalid date", write "March has 31 days. Please check the day".

• Missing required input: Instead of "Error", write "Please enter your email address".

• Failed login: Instead of "Login failed", write "The email address or password is incorrect. Check both and try again, or reset your password".

Ask only for what you need

Every extra field is one more chance to make a mistake. Request only the data you really need and do not ask for information you already have. WCAG 2.2 makes this explicit: information a user has already entered in the same process must be filled in automatically or offered for selection (WCAG 3.3.7).

Show conditional fields only when they are relevant. If someone selects "no children", the field for the children's ages should not appear at all.

Let users save their progress

Long and multi-page forms such as applications or tax returns take time. Show users which step they are on and how many steps are left. Let users save their entries and continue later, and never delete what they have entered when an error occurs or a session ends. For forms with legal or financial consequences, give users a chance to review, correct or cancel their submission before it is final (WCAG 3.3.4).

Login, CAPTCHAs and time limits

Logging in should not be a memory test or a puzzle. WCAG 2.2 introduced a criterion for exactly this: users must not have to remember, transcribe or work something out in order to log in, unless there is an alternative (WCAG 3.3.8).

In practice, this means:

• Allow pasting into password fields and support password managers. Never block the clipboard.

• Offer alternatives to passwords, such as passkeys, login links by email or two-factor authentication via an app.

• Avoid CAPTCHAs that ask users to decipher distorted letters or solve tasks. They are a barrier for people with learning difficulties and cognitive impairments, and image CAPTCHAs exclude blind users. An audio version alone does not solve this, as it excludes people who are deaf-blind. Invisible, behaviour-based bot protection or a honeypot field is a better choice.

Time limits put many people under pressure, for example screen reader users, people with motor impairments or anyone who reads more slowly. Login codes that expire after 30 or 60 seconds are a typical example. If a time limit cannot be avoided, users must be able to switch it off, adjust it or extend it, and they must be warned before time runs out (WCAG 2.2.1).

Video and audio in forms

Some forms explain steps in a video or include an audio message. Videos need captions, and audio content needs a transcript (WCAG 1.2.1 and 1.2.2). Even better: also give the key instructions as text directly in the form, so nobody depends on the media to fill it in.

Checklist: accessible forms at a glance

The relevant WCAG success criteria (version 2.2) are given in brackets.

• Every field has a visible label that is linked to it (1.3.1, 2.4.6, 3.3.2)

• Related options are grouped with fieldset and legend (1.3.1)

• Personal data fields use autocomplete (1.3.5)

• Text contrast is at least 4.5:1, field borders and focus at least 3:1 (1.4.3, 1.4.11)

• The form works at 200% text size and on small screens (1.4.4, 1.4.10)

• Everything works by keyboard, with a visible focus (2.1.1, 2.4.7)

• No single-key shortcuts, or users can switch them off (2.1.4)

• Time limits can be switched off, adjusted or extended (2.2.1)

• Click targets are at least 24 by 24 pixels (2.5.8)

• The accessible name contains the visible label (2.5.3)

• Required fields are announced and not marked by colour alone (1.4.1, 3.3.2)

• Error messages are specific and suggest a fix (3.3.1, 3.3.3)

• Important submissions can be reviewed and corrected (3.3.4)

• Data already entered is not requested again (3.3.7)

• Login works without memory tests or puzzles (3.3.8)

• Videos have captions, audio has a transcript (1.2.1, 1.2.2)

The full criteria are in the Web Content Accessibility Guidelines (WCAG) 2.2.

Conclusion

Accessible forms are not a special feature. They are what makes a form work for everyone. Clear labels, a logical structure, full keyboard operability, helpful error messages and fair login methods let people with disabilities, older people and people with temporary impairments complete forms on their own, and they make forms faster and less error-prone for all other users too. For businesses, every abandoned form means lost conversions – one of the hidden costs of an inaccessible website.

Want to know how accessible the forms on your website are? Start a free accessibility check with Eye-Able and get your results in less than 2 minutes, or talk to our accessibility experts.

FAQ: Accessible Forms

What makes an online form accessible?

An accessible form can be completed by everyone, including people who use assistive technologies, older people and people with temporary impairments. The key points are visible labels linked to every field, full keyboard operability, sufficient contrast, clear error messages and no time pressure or puzzles at login.

Which WCAG success criteria apply to forms?

The most important ones are 1.3.1 (Info and Relationships), 2.1.1 (Keyboard), 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions) and 3.3.3 (Error Suggestion). WCAG 2.2 added 3.3.7 (Redundant Entry) and 3.3.8 (Accessible Authentication), which also apply directly to forms.

Is a placeholder enough as a label?

No. Placeholder text disappears as soon as someone starts typing and usually has too little contrast. Use a visible labelelement for every field and add the placeholder only as an extra hint, if at all.

Do I need ARIA attributes for accessible forms?

Usually not. Native HTML form controls with a linked label element are already accessible. ARIA attributes such as aria-describedby or aria-required are useful for linking hint texts and error messages and for custom controls that HTML cannot provide.

Are CAPTCHAs accessible?

Most are not. Image and text puzzles exclude blind people and people with cognitive disabilities, and audio CAPTCHAs exclude people who are deaf-blind. Invisible, behaviour-based bot protection or a honeypot field protects forms without a test for users.

Are accessible forms a legal requirement?

In many cases, yes. In the EU, the European Accessibility Act (EAA) has applied to many digital products and services, such as online shops and banking, since 28 June 2025. In the UK, the Equality Act 2010 requires reasonable adjustments, and public sector websites must meet WCAG. In the US, the Americans with Disabilities Act and Section 508 set similar requirements. Most of these accessibility laws refer to WCAG 2.1 level AA as the technical standard.

How can I test whether my forms are accessible?

Start with three quick checks: fill in the form using only the keyboard, zoom the page to 200% and try the form with a free screen reader such as NVDA. An automated accessibility check finds many technical issues such as missing labels or low contrast. A manual audit by accessibility experts covers what tools cannot judge, such as whether error messages are helpful.