A form can look clean and still be difficult to use. If I only click through it with a mouse, I can miss a hidden focus indicator, an unnamed field or a message that somebody using a screen reader never hears.
I want to include those checks while building. They belong beside mobile layout and validation, because people need to understand the form before they can complete it.
Here is the review I would use for a simple contact form. The example is small enough to follow, but the same questions matter in profile editors and sign-up screens.
I start with visible labels
A placeholder can suggest what to enter, but it disappears when someone types. I prefer a visible label that stays beside the field.
For a normal HTML input, I connect the label to the input using matching for and id values. The name attribute has another job: it identifies the submitted field. Giving an input a name does not replace its accessible label.
<label for="contact-email">Email address</label>
<input id="contact-email" name="email" type="email"
autocomplete="email" aria-describedby="email-help">
<p id="email-help">Use an address where you can receive a reply.</p>This is a markup example to adapt and test. I still need the surrounding form, validation and submission handling.
The instruction should arrive before the mistake
If a field has a limit or a required format, I want to explain it before submission. Somebody should not spend time writing a message and only then discover that it is too long.
Instructions need to be specific. “Enter valid information” does not explain much. A useful instruction says which information is needed and gives a relevant example where that helps.
I also distinguish required fields in words or another clear indication. A colour change alone can be easy to miss.
I put the mouse aside
I start near the top of the page and use Tab to move through the controls. I check whether I can see the focus, whether the order follows the page, and whether I can reach the submit action.
Then I use Shift and Tab to move back. If a menu or dialog is part of the form, I check that I can open it, operate it and leave it without getting trapped.
I prefer native controls for ordinary jobs. Replacing a button with a clickable div can create extra keyboard and accessibility work before it delivers any benefit.
I want errors connected to the field
When validation fails, the message should identify the field and explain what needs fixing. For the email field, I could say, “Enter an email address such as name@example.com.”
The field can reference its error text using aria-describedby, and aria-invalid can communicate that the value is invalid. I need to update these states when the problem is corrected, rather than leave the field marked wrong forever.
For a longer form, an error summary can help somebody locate several problems. Its links should take them to the relevant controls. I also preserve values that are already valid.
Submission needs understandable feedback
A message changing visually is not enough evidence that assistive technology will announce it. I need to choose an appropriate status or live-region approach and test the result.
I do not want every keystroke announced as a new alert. Feedback should match the importance of the event. A successful submission and a blocking error deserve clear messages without making the whole form noisy.
During a slow request, the person should understand that submission is underway. When it fails, I keep their message available and explain what they can try next.
I test more than one way through
- Complete the form with the keyboard.
- Check each field's label and instructions.
- Submit missing and invalid values.
- Check focus after a validation failure.
- Read feedback with a screen reader where available.
- Zoom the page and check that controls remain usable.
Passing this small review does not prove complete accessibility. It gives me concrete problems to catch early. I want the form to work for the person using it, including when their way of interacting is different from mine.
References: W3C WAI: labeling controls and form notifications.