The Keyboard Test: A Pre-Handover Accessibility Sweep for Website Builds

You've checked the site in Chrome. You've checked it in Safari. You've fixed the footer that broke on tablet and you've stopped noticing the cookie banner. Before you zip the final files and send the handover email, there's one more pass worth doing — and it takes about fifteen minutes.

Accessibility has a reputation as a specialist bolt-on: something you bring in an auditor for, or something that only matters if the client is a council or a hospital trust. In practice, most of the checks that stop a build from being quietly unusable are ordinary delivery checks. They belong in the same final-files routine as checking links, proofreading the 404 page and making sure the favicon isn't still the CMS default.

In the UK, the Equality Act 2010 is the backdrop for a lot of this — it's the law that says services should be accessible to disabled people, and it applies to plenty of private businesses too, not just the public sector. Public sector clients have extra accessibility regulations to think about. This isn't legal advice and it isn't a compliance certificate. It's a practical sweep that catches the obvious stuff before a client, or their customers, catch it for you.

Start with the keyboard, not the colour picker

Put the mouse away. Actually away. Then tab through the site the way a keyboard-only user would.

Can you reach every link, button and form field? Does the focus ring show up clearly, or has someone — possibly you, at 11pm — set outline: none and forgotten to replace it? Is there a skip link at the top so someone can jump past the navigation? Can you get out of the cookie banner without getting trapped in a loop?

This is the five-minute check that reveals the most. If you can't complete the main task on a page using only Tab, Shift+Tab, Enter and the space bar, the page isn't finished. Test the contact form, the checkout, the newsletter sign-up — whatever the client actually wants people to do.

Contrast is a spot check, not a redesign

You don't need to audit every hex value in the stylesheet. Check the places where text sits on a background and squint at it honestly.

Body text should generally hit a contrast ratio of at least 4.5:1 against its background. Large text — roughly 18pt regular or 14pt bold — can get away with 3:1. Buttons, links, form labels and placeholder text are the usual offenders. Placeholder text in particular has a habit of being a polite shade of grey that vanishes in sunlight.

Use a contrast checker rather than your eyes. And check that colour isn't the only way you're communicating something: an error field outlined in red but with no message is still an inaccessible error field.

Alt text should describe the job, not the file name

Every informative image needs alt text that does the same job as the image. A photo of a studio workshop might need "Ceramics workshop with three people shaping clay on a wheel". A decorative swoosh needs an empty alt attribute — alt="" — so screen readers can skip it.

Don't start with "Image of". Don't stuff it with keywords. If the image is also explained in the caption, you can usually keep the alt text short. And if an image contains text — a poster, a graph, a screenshot — that text needs to appear in the alt text or nearby body copy, because not everyone will see the picture.

Forms need labels, not just placeholders

A placeholder is not a label. It disappears the moment someone starts typing, and it often fails contrast. Every input needs a visible label that stays visible.

Check the error messages too. If someone leaves a required field blank, do they get a message that says what went wrong and where? Is the error announced in a way that doesn't rely on colour alone? Are required fields marked in text, not just with an asterisk that nobody can decode?

This is also a good moment to check the form's success message. "Thank you" is fine. "Your message has been sent" is better. Silence is not.

Focus states are not decoration

A visible focus state is how keyboard users know where they are. If your design removes the browser's default outline, replace it with something at least as clear. A subtle box-shadow that only shows on a hover state isn't a focus state.

Tab through a page and watch the focus indicator move. If you lose it, so will someone else.

Reduced motion is a setting, not an edge case

If the site has parallax, autoplay video, scroll-triggered animations or a carousel that moves on its own, check what happens when someone has asked their operating system to reduce motion. The CSS media query prefers-reduced-motion is your friend here. At minimum, don't autoplay background video with sound, and give people a way to pause anything that moves.

Put it on the handover sheet

A fifteen-minute sweep won't make a site perfect. It will catch the things that make a client ask awkward questions two weeks after launch, and it gives you something concrete to point to when you say the build has been checked.

We've kept the checklist below to one page so it can go out with the handover email. Copy it into your own template, save it as a PDF, or paste it into the delivery note. Ask the client to sign it off alongside the rest of the final files. It's not a guarantee and it's not a legal audit, but it's a record that accessibility was part of the job — not an afterthought.

One-page pre-handover accessibility checklist

• Every page can be navigated with a keyboard alone
• Focus states are visible on links, buttons and form fields
• A skip link is present and works
• No keyboard traps (cookie banners, modals, carousels)
• Body text contrast is at least 4.5:1; large text at least 3:1
• Links and buttons are distinguishable without relying on colour alone
• Informative images have meaningful alt text
• Decorative images use empty alt attributes
• Form inputs have visible, persistent labels
• Error messages explain what went wrong and where
• Required fields are marked in text, not just with an asterisk
• Animations and autoplay respect prefers-reduced-motion
• Any moving content can be paused
• The client has received the checklist with the handover pack

Print it, tick it, send it. Then close the laptop. The launch party can start.