Building an Accessible Website: What Actually Counts in Code

Accessibility is not a feature you add to a website. It is a property of how the website was built - which is exactly why every attempt to generate it retroactively at the push of a button fails. If you want to know what actually sits behind the acronyms WCAG and EN 301 549, this is the list on which real sites succeed or fail.

Accessibility is a way of building, not a retrofit kit

The expensive route starts by building a finished site and then asking how to make it accessible. The cheap route is to make the same decisions differently from the outset: semantic HTML instead of a wall of divs, colours that already pass contrast in the design, components that work with a keyboard by default. Done that way the extra effort is marginal. Done afterwards it never is.

If you first want to know whether any legal duty applies at all, the boundaries are set out in who actually needs an accessible site. Beyond that, one point stands: we deliver the technical implementation, while the legal assessment of your specific case remains a matter for a solicitor.

Keyboard and focus: the test most sites lose

Put the mouse away and use nothing but the Tab key. This one check takes three minutes and exposes more defects than any automated tool.

• Focus is visible at all times. A focus ring removed in the design and never replaced is the single most common failure there is
• Order follows the visible layout, not the source order left behind by a grid rearrangement
• Every function is reachable: menus, sliders, accordions, video controls, the cookie dialog
• Nothing traps the focus. An overlay must close with the Escape key and return focus to where it came from
• A skip link to the main content appears on the first Tab press, so nobody has to walk through thirty navigation items

WCAG 2.2 tightened this further: the focused element must not be obscured by sticky headers or chat widgets, and controls need a minimum target size of 24 by 24 CSS pixels or sufficient spacing. Both land squarely on the designs that look current in 2026.

Contrast, structure and alt text

Contrast is where design and standard collide most often. Body text needs 4.5:1 against its background; large text from roughly 24 pixels, or 18.66 pixels bold, gets by at 3:1; interactive controls and meaningful graphics also have to reach 3:1. Pale grey on white almost always fails, and so does text over an image with no scrim behind it. Why a dark design does not automatically fix this is covered in dark mode versus light mode.

A second principle: colour must never be the only carrier of information. A form field outlined in red with no text beside it tells a share of your visitors nothing at all.

Structure means exactly one h1 per page, no skipped levels, and headings that genuinely name the section that follows rather than serving as decoration. Add the header, nav, main and footer landmarks so screen reader users can jump straight to the content. Alt text describes what the image contributes in context; purely decorative images take an empty alt attribute so they are skipped. The phrase "image of" is redundant, since assistive technology already says so.

Forms: where most conversions actually fail

Forms are the point where accessibility and conversion are the same thing. What sticks here costs you not just conformance but the enquiry itself.

Motion belongs in the same section because it shares a cause: effects nobody can switch off. Respect the reduced-motion system setting, drop animations that run longer than five seconds without controls, and avoid anything that flashes. How this interacts with mobile input is explored in mobile forms; the effect on loading and stability is covered in page experience.

Why overlay tools do not solve the problem

Overlays are scripts you drop in with a single line of code, promising to make a site accessible after the fact. That is attractive because it looks cheap. It does not work, for four concrete reasons.

First, a script cannot invent meaning that is absent from the markup. Whether an image is decorative or carries information, which heading belongs to which section, what an icon button triggers: none of that is written down anywhere, so none of it can be read out. Second, overlays intervene in an environment where users are already running their own assistive technology with their own settings, and sometimes disrupt it. Third, they change nothing about the underlying page, which still fails an audit. Fourth, they create a sense of completion that prevents the actual work from happening.

This is not a gut feeling. In the WebAIM survey of accessibility practitioners, 67 per cent rated overlays as not very or not at all effective; among respondents with disabilities that figure was 72 per cent, and only 2.4 per cent rated them very effective. The Overlay Fact Sheet, a statement signed by more than 570 practitioners worldwide, reaches the same conclusion. We do not recommend an overlay, not even as a stopgap, because a stopgap here only ties up the budget the real fix needs.

Concrete steps for the next 90 days

• Days 1-15: run the keyboard test across your three most important pages and note every point where focus vanishes or gets stuck
• Days 1-15: measure every text colour against its actual background, including text over images and buttons in their hover state
• Days 16-45: straighten out the heading hierarchy, add landmarks, review alt text and mark decorative images as empty
• Days 16-45: rework forms - visible labels, error text at the field, autocomplete attributes
• Days 46-90: walk the most important journey with a screen reader, ideally alongside somebody who uses one daily
• Days 46-90: document the result and publish it as your accessibility statement

Conclusion

Accessibility in code comes down to a small number of very concrete decisions, almost all of which can be made before the first line of CSS. Make them early and they cost you almost nothing; make them late and you pay for every single one. Whether you are obliged at all is settled in the accessibility act explained. What it costs and what it returns beyond legal certainty is worked through in the cost and benefit of accessibility.