A form can appear simple while being difficult for someone using a keyboard or assistive technology. Start with one real task, such as asking for a quote, and check whether the whole route is usable. The following first review follows the themes in W3C WAI guidance. It helps find problems but is not a complete accessibility audit or a claim of conformance.

Follow the route using only the keyboard

Put the mouse aside and move through links and controls with Tab and Shift+Tab. Check that focus remains visible and follows a sensible sequence. Activate the menu, open a service and reach the form. A dialogue should not leave the user lost behind it or trapped without an exit. Record the exact page and control where progress stops. W3C’s Easy Checks includes keyboard access and visible focus, but passing these checks does not demonstrate complete accessibility.

Make the form explain itself

W3C’s form guidance calls for controls to have labels that identify their purpose. A placeholder that disappears during typing is not a reliable substitute for a persistent label. In your customer review, check required fields, expected formats and what happens after submission. Use language the customer understands. For a hypothetical enquiry form, separate the optional company name from the required contact method so the visitor does not have to guess what prevents submission.

Check whether people can read and correct the information

Zoom the page and inspect headings, buttons and long text. Look for cropped content and controls that disappear. Submit a harmless test with a missing required field and see whether the error identifies the problem and the next step. Do not rely on colour alone to communicate success or failure. Ask the developer to review text alternatives for meaningful images. These are review prompts for a real task, not a shortcut to declaring the entire site accessible.

Prioritise the barrier and retest the same task

A blocked enquiry or payment step deserves attention before a minor decorative inconsistency. Send the developer a short record containing the URL, device, steps and observed difficulty. Include users with different access needs in evaluation where possible. After a fix, repeat the original task and check related controls. Keep accessibility in content production too, including captions and descriptive links. The goal is continuing access to the business, with honest reporting about what has and has not been assessed.

READ THE ORIGINAL SOURCES

Sources & further reading

Put the next step into practice.

Tell me about your business and we can discuss a practical plan.

Let’s talk on WhatsApp