Accessibility work becomes more difficult when it is treated as a final check. By the time a website reaches an audit, many of the important decisions have already been made. The colours have been chosen, the components have been built, the forms have been structured and the content model has been agreed. Fixing issues at that stage is still possible, but it often becomes more expensive than it needed to be.
I have started trying to bring accessibility into the project earlier, not as a separate phase but as part of ordinary design and development decisions. That means checking contrast before a visual direction is approved, thinking about keyboard behaviour while interactive components are being designed and making sure forms are structured properly before they are styled.
This does not require every conversation to become technical. It requires the team to ask better questions while the work is still flexible.
Starting With Design Decisions
A lot of accessibility issues begin in design decisions that look harmless. A pale colour combination feels elegant in the design file, but becomes difficult to read on a real screen. A custom dropdown looks clean, but creates keyboard and screen reader problems during development. A form layout feels minimal, but removes labels that people need to understand what they are completing.
These are not problems designers create because they do not care. They often happen because accessibility is reviewed too late. Once the design has been approved by everyone, changing it can feel like a step backwards. That is why the checks need to happen while the design is still being shaped.
I like to test the basics early. Can the text be read comfortably? Does the focus order make sense? Are interactive elements obvious? Does the page rely on colour alone to explain meaning? These questions are simple, but they prevent a lot of avoidable rework.
Building Components With Behaviour In Mind
Development is where many accessibility decisions become real. A design may show a modal, but the build has to decide how focus moves into it, how it closes, what happens with the escape key and how the page behind it is treated. A design may show tabs, but the build has to decide how those tabs work for someone using a keyboard.
This is why I prefer thinking about accessibility as component behaviour, not only as page compliance. If a component is used across a site, its accessibility decisions are repeated everywhere. A well-built component improves many pages. A weak component creates the same problem repeatedly.
The same applies to WordPress blocks and patterns. If the block output is accessible by default, editors are less likely to create problems accidentally. If the block depends on editors making perfect decisions every time, the system is fragile.
The Audit Should Confirm, Not Rescue
An accessibility audit is still useful. It can catch issues the team missed, provide an outside view and create a clear list of fixes. The problem is when the audit becomes the first serious accessibility conversation in the project. At that point, the audit is being asked to rescue decisions that should have been considered earlier.
I prefer the audit to confirm the direction rather than reveal the foundations are wrong. That means using smaller checks throughout the project. Test a component before it is used everywhere. Check a colour pairing before it becomes part of the system. Try the navigation with a keyboard before the site is nearly finished.
Those small checks reduce risk. They also make the final audit more useful because it can focus on genuine issues rather than avoidable mistakes.
Retrospective Thoughts
Accessibility is easier when it is part of the way the website is made. It should affect design, development, content and CMS decisions from the beginning. When it is treated as something added at the end, the work becomes harder and the result is usually weaker.
The aim is not to turn every early discussion into a standards document. The aim is to make accessible decisions ordinary. Use the right elements. Keep text readable. Make interactions work without a mouse. Give editors components that are hard to misuse.
That kind of work is not dramatic, but it changes the quality of the website. It makes the site more usable for more people, and it prevents accessibility from becoming a late-stage panic.