Accessible Website Forms: A Testing Checklist

Keep questions and labels clear

Ask only for the information needed at this stage. An initial enquiry may need an email address and a message; decide whether a phone number or postal address is necessary.

Check each field:

• Its label stays visible after typing.
• Required fields are identified in text.
• Instructions explain formats before submission.
• Radio buttons and checkboxes have a clear group question.
• The visible label matches the name available to assistive technology.

A placeholder disappears as soon as someone types, so use a proper label. Put help beside the relevant field: where to find a reference number, for example, or which file formats are accepted.

The W3C forms tutorial explains labels, instructions and grouping.

This remains a common defect: WebAIM's February 2026 automated study of one million homepages found that 33.1% of the form inputs it detected lacked proper labels. That makes labels a worthwhile first check, even on a simple form.

Complete the form with a keyboard

Use Tab and Shift+Tab to move through the controls. Check that focus is visible and follows a sensible order.

Try every dropdown, date picker and upload control. Confirm that you can select an option, change it and continue. If the form opens in a dialog, check that closing it returns you to the page.

Record the exact failure. “Tab gets stuck in the location dropdown” gives a developer something to reproduce.

Submit incorrect information

Leave a required field empty, enter an invalid email address and try an unsupported file.

An error should name the problem and explain the correction. “Enter an email address in the format [email protected]” gives more help than “Invalid input.”

Check that:

• Errors appear beside the affected fields and are associated with them.
• Colour is accompanied by text.
• An error summary helps users reach the fields that need attention.
• Answers already entered remain in place.
• Correcting a field removes its old error state.

Test the second submission as carefully as the first. W3C's form notification guidance covers error feedback and confirmation.

Try the working example

Open the form demonstration. It runs in your browser and sends nothing. Use fictional details.

1. Submit the empty form.
2. Follow an error-summary link to its field.
3. Enter a name, message and incorrectly formatted email.
4. Submit, correct the remaining error and submit again.
5. Repeat with a keyboard.

The example shows labels, linked errors and confirmation. A production form also needs server-side validation and submission handling.

Check mobile, zoom and screen reader use

Narrow the window and zoom the page. Look for clipped controls, overlapping text and errors hidden outside the visible area.

Check the form with assistive technology as part of the agreed assessment. Automated checks can find some structural problems, but a person still needs to judge whether the instructions and recovery steps make sense.

For uploads, check file restrictions, progress, failure messages and whether a failed upload clears other answers.

Check the easily missed WCAG 2.2 requirements

• Repeated information: within the same process, information already supplied should be filled in or available to select again, subject to essential, security and validity exceptions. Browser autocomplete alone does not satisfy this requirement. Redundant Entry, 3.3.7.
• Login and verification: allow password managers and pasting. If a code is split into separate boxes, test pasting the whole code; filling only the first box leaves the user to transcribe the rest. Accessible Authentication, 3.3.8.
• Small controls: the minimum target-size criterion uses 24 × 24 CSS pixels, with spacing and other exceptions. Check checkbox targets, help buttons and close controls as well as Submit. Target Size, 2.5.8.

Our ROH Wheels quote process carries the selected wheel and vehicle into the enquiry and includes PIN verification. A flow like this needs checks on the handover and code entry as well as the initial contact fields.

Confirm what happened

After submission, tell the visitor whether their request was received and what happens next.

Check that the message can be perceived by assistive technology. If processing fails, provide a recovery option that avoids losing the visitor's work.

On the receiving side, verify that the enquiry reaches the intended team. This is a separate check from seeing the browser's confirmation.

Record and retest issues

Use the form review worksheet to note the page, browser, input method, action and result. Fix problems that prevent completion first, then repeat the failed task.

Our Brisbane web design team can review forms as part of a website redesign.