Accessibility basics: six fixes that cover most of the problem

Accessibility gets treated as a specialist compliance project, and that framing is why it never gets started. In practice, a small number of specific issues account for most of what genuinely blocks people from using a site, and each has a clear fix.

Here are six, with how to test each one yourself in a few minutes.

1. Keyboard navigation

Put the mouse aside and use Tab, Shift-Tab and Enter to get through the site. Can you reach the navigation? Open the menu? Fill and submit the form? Close a modal?

Custom components are the usual failure: a div styled as a button is not focusable and does not respond to Enter. Use real `button` and `a` elements, and the behaviour comes free.

2. Visible focus states

A very common and very damaging fix-that-broke-things: someone removed the focus outline because it looked untidy. Now a keyboard user has no idea where they are on the page. If you do not like the default, replace it with something better. Do not delete it.

3. Colour contrast

Light grey text on white is the signature of a design that was reviewed on one good monitor in a dim room. It fails outdoors, on cheap screens, and for anyone with reduced vision, which is a large and growing group.

4. Alt text that says something

Alt text describes what the image conveys, not what it literally contains. "Chart showing sales doubling between March and June" is useful. "chart.png" is not. And genuinely decorative images should have empty alt text so screen readers skip them rather than announcing noise.

5. Form labels

Placeholder text is not a label. It disappears the moment someone types, it often fails contrast requirements, and screen readers do not treat it as a label. Use a real `label` element associated with the input. This is also the single most common accessibility fault on business websites.

6. Heading structure

Headings are a document outline, not a font size menu. One h1, then h2 for sections, h3 for subsections, in order. Screen reader users navigate by heading, so skipping from h1 to h4 because it looked right removes their primary way of moving through the page.

What automated testing can and cannot tell you

Be clear about the limits. Automated tools reliably catch contrast failures, missing alt attributes, missing labels and heading order problems. They cannot tell you whether your alt text is meaningful or whether a custom component makes sense to a screen reader user. Those need a human.

So use both. siteIQ produces accessibility reports as part of its audit pass, which handles the mechanical checks, and then you test the keyboard path yourself. For design work where accessibility is built in rather than retrofitted, CodeAiMan's UI/UX team works with contrast and focus requirements as constraints from the start, and their web development practice implements them.

Frequently asked questions

Referenced in this article