Sign in Get started
Solutions
ComplianceDigital ForensicsAccount SecurityWebsite SecurityWeb OptimizationSEO / GEOBusiness IntelligenceUI / UXStartupsDigital TransformationWhite LabelAI Code AuditAI / MLConsulting & AdvisoryBusiness Strategy
Products
Web HostingVPS HostingSSL CertificatesSiteLock SecurityWebsite BackupEmail Spam FilterOX App Suite360 MonitoringWeebly BuilderSite BuilderSEO (Marketgoo)Account SecurityDomainsAll Products
More
NetworkSecurity AboutCareersContactRoadmapLegal
Blog

Designing forms everyone can use

Forms are where a website asks something of its visitors: an order, a booking, a sign-up. Every unclear label or vague error costs completions. Designing for people who use a keyboard, a screen reader or a magnifier makes the form better for everyone.

This guide combines everyday form design with the basics of the Web Content Accessibility Guidelines. The current version is WCAG 2.2, a W3C Recommendation since October 2023, updated in December 2024. Level AA is the usual target in contracts and in law.

An accessible form field with a label, a hint, an error message and a buttonE-mail addressWe send your receipt herenikos.example.comAdd an @, like [email protected]Continue12341Label above the fieldAlways visible, tied to the input2Hint outside the boxIt stays when the user types3Error in words, next to itSays what is wrong and how to fix it4A large, clear buttonAt least 24 by 24 pixels, 44 is kinderE-mail addressWe send your receipt herenikos.example.comAdd an @, like [email protected]Continue12341Label above the fieldAlways visible, tied to the input2Hint outside the boxIt stays when the user types3Error in words, next to itSays what is wrong and how to fix it4A large, clear buttonAt least 24 by 24 pixels, 44 is kinder
One field, done well. The error is marked by a colour, an icon and words, so it reaches people who cannot see the red.

Ask for less

List every field and ask what happens to the data. If nobody uses it, remove it. If you only need it sometimes, ask for it later.

WCAG 2.2 added a rule on exactly this, Redundant Entry (3.3.7, Level A): do not make people type the same information twice in one process. Offer "same as delivery address" or fill it in for them.

Lay it out in one column

  • One field per row. A single column gives one clear path down the page and works the same on a phone.
  • Labels above the fields. They are easy to scan and do not get squeezed on narrow screens.
  • Group related fields under a short heading, such as "Delivery" and "Payment". In code, a fieldset with a legend tells screen readers about the group too.
  • Show short lists as options. For a handful of choices, radio buttons are quicker than a drop-down that hides them.

Label every field properly

Every input needs a visible label that stays on screen. Placeholder text inside the box is no substitute: it disappears as soon as someone types, it is often too faint to read, and people mistake it for a value already filled in. Put hints and format examples below the label, outside the box.

In code, connect each label to its input with <label for>, so a screen reader announces it and a click on the label focuses the field. Mark which fields are required, in words or with a symbol you explain at the top of the form. Add autocomplete values such as email, name and postal-code. Browsers can then fill them in, which WCAG covers under Identify Input Purpose (1.3.5).

Write errors that help

An error message has three jobs: say that something went wrong, say where, and say how to fix it.

  • Place the message next to the field, and repeat a summary at the top of a long form with links to each problem.
  • Use words and an icon as well as colour. Red alone does not reach people with colour blindness.
  • Be specific. "Enter a date like 14/03/2026" helps. "Invalid input" does not.
  • Check a field when the user leaves it or submits the form, never while they are still typing.
  • Keep what the user entered. Clearing a whole form after one mistake is the fastest way to lose them.

Make it work with a keyboard

Many people never touch a mouse. Tab through your form from top to bottom. The order should follow the visual order, and every field, link and button must be reachable and usable.

The element in focus must be clearly visible, with an outline that has enough contrast against the page. WCAG 2.2 adds that a focused element must not be completely hidden by something else, such as a sticky header or a cookie banner (Focus Not Obscured, 2.4.11).

Size, spacing and contrast

Small targets are hard to hit for anyone with a tremor, a large finger or a moving bus. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels at Level AA, with exceptions such as links inside a sentence or small targets with enough space around them. A tap area of 44 by 44 pixels, the Level AAA figure, is more comfortable on phones.

For contrast, body text and labels need a ratio of at least 4.5 to 1 against their background, and large text at least 3 to 1. Field borders, icons and focus outlines need at least 3 to 1, so people can see where the fields are.

The WCAG 2.2 checks for a form

CheckWCAG reference
Visible labels and instructionsEvery field, tied to its input in code3.3.2 Labels or Instructions (A), 1.3.1 Info and Relationships (A)
Errors in words, with a fixNever by colour alone3.3.1 Error Identification (A), 3.3.3 Error Suggestion (AA), 1.4.1 Use of Color (A)
Keyboard and focusVisible focus, never covered2.1.1 Keyboard (A), 2.4.7 Focus Visible (AA), 2.4.11 Focus Not Obscured (AA)
Targets at least 24 by 24 pxOr enough spacing around them2.5.8 Target Size (Minimum) (AA)
ContrastText 4.5:1, borders and focus 3:11.4.3 Contrast (Minimum) (AA), 1.4.11 Non-text Contrast (AA)
No retyping, no puzzles to sign inAllow paste and password managers3.3.7 Redundant Entry (A), 3.3.8 Accessible Authentication (AA)

Accessible Authentication (3.3.8) matters for sign-in forms. Do not make people solve a puzzle or remember and retype a code without help. Allow pasting into password fields, support password managers, and offer an alternative to image challenges. Passkeys and e-mailed sign-in links pass easily.

Test with real people and real tools

Automated checkers catch missing labels and low contrast, and they miss most of what makes a form hard to use. After the automated pass, complete the form with only a keyboard, then with a screen reader such as NVDA or VoiceOver, then at 200% zoom on a phone.

In the EU, the European Accessibility Act has applied since 28 June 2025 to many consumer services, online shops included. If you build forms for clients on Internetivo, Getting paid on Internetivo explains how approved milestones are paid.

Common questions

Is WCAG 2.2 the latest version?
Yes. WCAG 2.2 is the current W3C Recommendation, and it is also published as the international standard ISO/IEC 40500:2025. WCAG 3 is still an early draft.
Can I use floating labels?
Only if the label stays visible and readable after the user types, and the contrast holds in every state. A plain label above the field is simpler and safer.
Are drop-downs bad?
They hide the options. For a few choices, radio buttons are faster. For a long list such as countries, a drop-down or a search field is fine.
Should I mark required or optional fields?
Mark whichever group is smaller, and explain the marker. Best of all, remove optional fields you do not really need.
What is the quickest test?
Put the mouse away and complete the form with the keyboard. It finds focus, order and label problems in a few minutes.

Pick one form on a site you look after and run the keyboard test today. It is the quickest way to see what your visitors see.