Insights

Accessibility is often treated as one of the last jobs in a website project.

The design has been approved. The pages have been built. Content has been entered and launch is approaching. Someone runs an automated test, a list of warnings appears, and accessibility becomes a collection of items to fix before everybody moves on.

By then, many of the most important decisions have already been made.

The colour palette may not provide enough contrast. The navigation may rely on interactions that only work with a mouse. Headings may have been chosen for their size rather than their meaning. Forms may ask for information without making errors easy to understand.

These are not finishing touches. They are part of how the website works.

Accessibility begins before the first screen is designed

An accessible project starts by understanding who needs to use the website and what they need to accomplish.

That includes people who navigate with a keyboard, use screen-reading or magnification software, have reduced vision or colour perception, process information differently, experience limited movement, or are working with a temporary injury. It also includes somebody standing outside in bright sunlight, using a cracked phone, trying to complete a form with one hand or dealing with a slow connection.

Accessibility is specifically concerned with removing barriers for people with disabilities, but thoughtful decisions often improve the experience much more broadly.

This is why website accessibility needs to influence planning, content, design and development from the beginning.

Design decisions can create barriers immediately

A beautifully restrained colour palette is not useful if important text cannot be read against its background. A subtle focus style may suit the visual design while leaving keyboard users unable to see where they are. An interface built around hovering can hide information from touch devices and people who do not use a pointer.

Accessible design asks practical questions while there is still room to respond:

• Does text remain readable at different sizes and widths?
• Can colour choices meet suitable contrast levels?
• Is meaning communicated by more than colour alone?
• Are interactive elements recognisable and consistent?
• Does the layout retain a sensible order when enlarged or rearranged?
• Can error, success and selected states be understood clearly?

Addressing these questions during website design and development is more effective than trying to repair a completed interface without changing its appearance.

Content has its own accessibility

Even technically correct pages can be difficult to understand.

Long walls of text, vague link labels, unexplained acronyms and headings that do not describe their sections make content harder to navigate. Documents can introduce another layer of problems when important information is locked inside an inaccessible PDF.

Good structure gives readers choices. Descriptive headings allow somebody to scan a page or move through it using assistive technology. Meaningful link text explains what will happen without relying on the surrounding paragraph. Instructions that are clear and specific reduce mistakes.

Alternative text for images also needs judgement. A decorative image may require no description, while a chart or diagram may need its important meaning explained in the surrounding content. Filling every image with a string of search keywords does not make it accessible.

Development determines whether the interface keeps its promises

A button can look like a button without behaving like one.

If an interactive element is built using the wrong HTML, it may not receive keyboard focus or communicate its role to assistive technology. A custom menu may appear straightforward with a mouse but become impossible to operate by keyboard. A modal window may open visually while focus remains somewhere behind it.

Semantic HTML provides useful behaviour before additional code is written. Native buttons, links, headings, labels and form controls carry meaning that browsers and assistive technologies already understand.

Development and accessibility therefore belong together. The objective is not only to reproduce the approved screen, but to make its structure and interactions dependable across different ways of using it.

Automated tests are useful, but incomplete

Automated testing can identify missing labels, invalid structure, contrast failures and other detectable issues quickly. It is valuable throughout development and during ongoing maintenance.

It cannot decide whether alternative text communicates the right information. It cannot reliably determine whether the reading order makes sense, whether instructions are understandable or whether a complex interaction is practical to use.

A tool might confirm that a form field has a label. A person still needs to determine whether that label is clear, whether the error message helps and whether focus moves somewhere useful after submission.

This is why an accessibility review combines automated checks with manual testing of important templates and user journeys. A broader website audit can also examine how accessibility interacts with content, performance, search and conversion.

Launch is not the end of accessibility

A website that launches in good condition can become less accessible over time.

New colour combinations are introduced in campaign pages. Editors paste headings based on appearance. Videos are uploaded without captions. Plugins change interfaces or add controls that have not been tested.

Maintaining accessibility requires usable content guidelines, suitable templates and periodic checks of the journeys that matter most. It also requires a way for people to report a problem and confidence that somebody will respond.

Build it into the definition of done

Accessibility works best when it is part of every decision rather than owned by the final person in the project timeline.

That does not mean every project begins with perfect knowledge or that no issue will ever reach testing. It means accessibility is considered when choices are still being made, and testing verifies those choices instead of attempting to rescue them.

A checklist remains useful.

It just should not be the first time anybody asks whether everyone can use what has been built.