Website accessibility: the checks that help people use it

The fastest way to find out if a site can actually be used is to try filling out the quote request form without touching the mouse. If you can't — because the cursor disappears, because a field can't be reached, because the button doesn't respond — then there's someone out there who can't write to you, and you'll never know it: someone who can't get through doesn't send a report, they close the page.

Accessibility is verified on paths, not on pages in the abstract. The paths that matter are two or three: finding the service, understanding whether it fits your case, asking. This guide helps you check them with your own hands and turn what you find into assigned fixes.

Four checks you can do in ten minutes, without tools

1. The keyboard. From the top of the page, using the Tab key, you should be able to reach every link, every field, and every button, in an order that follows the reading flow. Try opening the menu, closing a window that pops up on its own, submitting the form.
2. The focus indicator. As you move with the keyboard, you should always be able to see where you are: an outline, a color, something. Many themes remove it because it's considered unattractive: it's the most common defect and also the easiest to fix.
3. Contrast. Light gray text on white, text over a photograph, buttons with a label nearly the same tone as the background. These are the points where you lose anyone reading a screen in sunlight or with tired eyes — which is almost everyone, sooner or later.
4. Heading hierarchy. One main heading per page, then sections and subsections in order, with no skips and no headings used just to make text bigger. That's how a page gets scanned when it isn't seen all at once.

Images, forms, and error messages

The second round is about what a page communicates when it isn't viewed as a whole.

• Alt text: it describes what the image is there for at that point, not what it shows. A logo is described with the company name; a decorative photo doesn't need a description; a diagram that carries information needs to be described in full, or the information needs to be written in the text too.
• Field labels: every field has its own label, visible and linked to the field. The gray text inside the box isn't a label: it disappears the moment you start typing, and anyone who gets distracted no longer knows what they were filling in.
• Error messages: they need to say which field and what to fix, stay visible, and not rely on color alone. A red border isn't a message.
• Required fields: they're stated upfront, not after a failed submission attempt. And the form shouldn't erase what was already typed in.

Automated tools and manual tests

Automated tools are useful and not enough: they find what can be counted, not what makes sense. You need both, and it's worth knowing what to expect from each.

The practical rule: run the automated check once to clear out the bulk of it, then at every publication; redo the manual test every time the main paths change, because it's the only one that tells you whether a person makes it all the way through.

A test protocol for the quote request

Written once, it's repeated the same way every time the site changes. One person runs it, in half an hour, noting where they got stuck and what they had to guess.

1. Open the homepage and reach the service page using only the keyboard. Note how many steps it takes and whether you can always see where you are.
2. Zoom the text with the browser command up to double size. Check that nothing disappears, that the menu still opens, and that no horizontal scrollbar appears.
3. Fill out the form with the keyboard, deliberately leaving a required field blank and getting the email address wrong. Check that the error is written out, reachable, and understandable without looking at the color.
4. Correct it and submit. Check that the confirmation is text you can read and find again, not just a color change or an icon.
5. Repeat the path on a phone, with one hand, and then with the screen turned horizontal.
6. Repeat the first step with a screen reader turned on, even just the one already built into the operating system. You don't need to be an expert to notice that a button is announced as "button" and nothing else.

Assigning fixes and checking again

A list of problems with no name attached doesn't produce fixes. Every entry needs four pieces of information: where it happens, what it prevents you from doing, who fixes it, how you verify it's resolved. The order isn't the order in which the problems were found.

• First, whatever prevents a path from being completed: a form that can't be submitted comes before slightly weak contrast.
• Then, whatever repeats across the whole site: an invisible focus indicator or missing labels get fixed once in the page template and apply everywhere.
• Finally, the individual cases, page by page, which are often content rather than code: a description to rewrite, a heading used in the wrong place.
• After every fix, redo the full protocol on the paths that were touched. Accessibility fixes come undone easily at the first design change or the first new component added.

What this guide doesn't cover

This guide checks whether the site can be used, not whether it complies with a legal requirement: the applicability of regulations, formal audits, and any required statements need dedicated expertise and should be assessed separately. It also doesn't cover which questions to put in a contact form, which is a matter of content rather than accessibility, nor the general testing done before going live, which includes many other checks besides these.