Someone lands on your signup form and can’t use a mouse, so they move through the page with the Tab key. They reach the email field, type their address, press Tab again, and nothing happens: the button that submits the form can’t be reached from the keyboard. They’re stuck, so they leave, and you never learn they were there.
That person might be using a keyboard because of a hand injury, or a screen reader because they’re blind, or high-contrast mode because their sight is fading with age. They wanted to use your product. Something in the code shut them out.
I want to help you find those walls before your users do. In the UK there’s also a legal dimension. The Equality Act 2010 asks service providers to make reasonable adjustments so disabled people can use their services, and websites and apps are covered. Enforcement is growing, and public-sector sites have their own regulations on top. I’m an engineer, not a solicitor, so treat this as a practical starting point rather than legal advice. What follows is a set of checks you can run yourself in an afternoon.
The encouraging thing is that generated code usually gets the visible layout right, so it looks fine on your screen. What breaks tends to be the part you can’t see by looking: the things screen readers announce and keyboards rely on. A bit of testing goes a long way.
1. The keyboard-only test
This is the single most revealing thing you can do, and it costs nothing. Unplug your mouse, or put it out of reach, and try to use your whole app with the keyboard.
Tabmoves you forward through buttons, links and form fields.Shift+Tabmoves you back.Enteractivates a link or button.- Arrow keys move within a menu, a set of radio buttons or a dropdown.
Every button, every link and every form field must be reachable and usable this way. And you must be able to see where you are. As you press Tab, a visible outline should move around the page, landing on each element in turn. That outline is called the focus indicator, and AI-generated code often removes it because someone thought it looked untidy. Without it, a keyboard user is navigating blind.
To check it: Put the mouse away. Start at the top of a page and Tab all the way through. Can you reach everything? Can you always see where you are? Can you open your menu, fill in a form and submit it, using only the keyboard? Note anything you cannot reach or cannot see.
2. Colour contrast
Light-grey text on a white background is one of the most common defaults in generated designs. It looks calm and modern. It’s also hard to read for a lot of people: anyone with low vision, anyone over about fifty, anyone using a phone in bright sunlight.
There’s a measurable standard for this. The WCAG guidelines set a contrast ratio, and the level to aim for is called AA. Normal-sized body text needs a ratio of at least 4.5 to 1 against its background. You don’t need to calculate that by hand.
To check it: Open your browser’s built-in audit (in Chrome, that is the Lighthouse tab in developer tools) and it will flag low-contrast text for you. Or paste your text colour and background colour into a free online contrast checker and it will tell you the ratio and whether it passes AA. If any of your body text fails, darkening the grey is usually a small change.
3. Labels and alt text
Two things here, both invisible on screen, both essential to a screen reader.
- Form fields need real labels. A label is a bit of text tied to a field in the code, using a
<label>element, so that a screen reader announces “Email address, edit text” when the user arrives. Placeholder text (the faint grey hint inside a box) isn’t a label. It vanishes when someone starts typing, and screen readers treat it inconsistently. - Meaningful images need
alttext. Thealtattribute is a short written description of an image. A screen reader reads it aloud, so a blind user knows what the picture shows. Decorative images can have emptyalttext so they’re skipped, but a photo, chart or logo that carries meaning needs a real description.
To check it: Look at your form code for a <label> on each field, or ask your AI tool to “add a proper label element tied to each input”. For images, check that important ones have an alt attribute with a sensible description. An automated checker (see section 7) will list images and fields that are missing these.
4. Headings and structure
Screen-reader users often navigate a page by jumping from heading to heading, the way a sighted person skims. For that to work, the headings need to describe the structure of the page rather than be chosen for how they look.
The rule is straightforward. One h1 per page, the main title. Then h2s for the main sections under it, and h3s for subsections within those. It should read like an outline. AI sometimes picks a heading level because it produces the right font size, so you end up with an h4 chosen for looks sitting above an h2, which makes the outline nonsense to anyone listening to it.
To check it: Install a free browser extension that shows the heading outline (search for a “headings” or “accessibility” extension), or right-click an element and choose Inspect to see whether that big title is coded as an h1. Read the outline top to bottom. Does it make sense as a table of contents?
5. Forms and validation
This is where most people get stuck, so it’s worth the most care. A form has to do more than collect answers. It has to explain, clearly, when something goes wrong.
- Every field has a clear label, as in section 3.
- Errors are explained in words, next to the field they belong to. “Please enter a valid email address” beside the email box, not a lone red border. Colour alone excludes anyone who can’t distinguish red from the rest, and it tells nobody what the problem is.
- Focus moves to the problem. When a user submits a form with an error, the page should move their cursor to the first field that needs fixing, so a keyboard or screen-reader user is taken straight there rather than left hunting.
To check it: Submit your forms wrong on purpose. Leave a required field blank, type a bad email. Do you get a message in words, right next to the field? Now do the same with only the keyboard. Are you taken to the problem, or left stranded?
6. Zoom and mobile
People with low vision often enlarge the page. Your layout needs to cope with that without hiding or cutting off content.
To check it: In your browser, zoom to 200% (press Ctrl and +, or Cmd and + on a Mac, until you reach 200%). Nothing should overlap, disappear off the side or get clipped. Text should reflow to fit. Then open the same pages on an actual phone and walk through them. Small tap targets, cut-off buttons and forms that will not scroll show up quickly on a real device.
7. Automated tools help, but they do not finish the job
Two free tools will find a good chunk of problems for you. Chrome’s built-in Lighthouse audit (in developer tools, the same place as the contrast check) gives you an accessibility score and a list of issues. The axe browser extension is the other one I reach for, and it explains each problem in plain terms.
Run both. They’re worth the ten minutes. But be honest with yourself about their limits. Automated tools catch somewhere around half of accessibility issues, the ones a machine can measure: missing labels, poor contrast, absent alt text. They can’t tell whether your keyboard order makes sense, whether your error messages are understandable, or whether a screen reader user could complete a purchase. The keyboard test from section 1 finds the half the tools miss. You need both.
Where to start
If you do nothing else this afternoon, do these two things. Run the keyboard-only test on your main flow: signup, and whatever your core action is. And run a contrast audit on your text. Between them they surface most of the walls that shut people out, and both are quick.
Fix what you can, and write down what you can’t. That list is genuinely useful, and it sits naturally alongside the other launch questions in the full launch checklist.
If it feels like a lot, that’s a fair reaction, and it’s the part of my work I enjoy most. I can go through your product properly, tell you plainly where it shuts people out, and give you a prioritised plan for putting it right. No judgement about how you built it, and no obligation. You set out to build something people can use, and I can help you make sure that includes the ones who are easiest to shut out by accident.
