Skip to content
Felix Schumann
Editorial illustration: Accessible contact forms: An enquiry should work without a mouse
Journal / 22

Accessible contact forms: An enquiry should work without a mouse

Felix Schumann·

A contact form can look polished and still lose people before submission. Keyboard, screen-reader and small-screen users need identifiable controls and understandable feedback. On my portfolio I connected contact enquiries and appointment booking to a custom dashboard. Good web development checks the whole route to a received enquiry.

Research checked: 2026-09-11 · Cover: AI-generated illustration

Keep labels available while people type

W3C WAI explains how to associate form controls with labels. A placeholder disappears during input and does not provide the same persistent explanation.

I would identify required fields directly and explain format requirements before submission. A phone-number field should also accommodate an understandable international format. People should not have to infer the expected input from a failed attempt.

W3C WAI: Labeling Controls ↗

Complete the task with the keyboard

My first manual test avoids the mouse: reach every field, change a selection, close the dialog and return to the contact button that opened it. Focus must remain visible and follow a logical order.

An additional appointment dialog can make this confusing. The active dialog must be identifiable. On mobile, the keyboard consumes screen space, so it should not conceal essential actions.

The decision at a glance

  1. 01UnderstandIdentify fields and requirements
  2. 02InteractCheck keyboard and small screens
  3. 03ConfirmExplain the actual outcome
Our schematic illustration of the proposed approach, not measured data.

Explain errors and preserve input

WAI recommends understandable feedback for both errors and successful actions. A message should identify the affected field and explain how to correct it. An unexplained technical error does little to help the person continue.

I would retain entered content after a temporary failure and distinguish acceptance from remaining steps. If email verification is required, the interface must not claim that the entire enquiry is already complete.

W3C WAI: User Notification ↗

What I would test before accepting a website

The review covers keyboard interaction, narrow screens, invalid details, network failures and a complete successful submission. It also checks whether the enquiry appears in the intended dashboard. A screenshot of the form cannot establish that.

If you need a new website or improvements to an existing form, I can assess the interface and backend together. Start with a concrete visitor task. A usable workflow removes unnecessary obstacles; a specific conversion improvement still requires measurement.

Sources and further reading