I have become less patient with accessibility being treated as a final check.
The problem with leaving it until the end is that many accessibility decisions are not surface-level fixes. They are built into the structure of the interface. A button that should have been a link, a modal that traps focus poorly, a form that does not explain errors clearly or a card that relies entirely on hover cannot always be corrected properly with a few small changes after everything else has been approved.
In 2023, with accessibility guidance becoming more mature and clients more aware of their responsibilities, I think the timing matters. Accessibility needs to be part of the first design conversation, not a separate exercise carried out once the build is nearly finished.
Starting With The Behaviour
The first question I ask now is not what a component looks like. It is what the component does. Is it navigation? Is it disclosure? Is it a form control? Is it a decorative card? That distinction matters because the behaviour should shape the markup, keyboard interaction and screen reader experience.
A clickable card is a good example. It might look simple in a design file, but the implementation needs thought. Should the whole card be a link, or should only the title be linked? Are there multiple actions inside the card? Does the hover effect also have a focus state? What happens when someone tabs through a list of ten cards?
Those questions are easier to answer before the design becomes too fixed. Once the design has been signed off, changing the interaction model can feel like undoing work. That is why accessibility should be discussed while the component is still being shaped.
Forms Reveal The Most
Forms are usually where accessibility decisions become most visible. A form can look clean and still be difficult to use if labels are missing, errors are vague or keyboard focus moves unpredictably. The visual design might only show the default state, but real users meet required fields, validation messages, disabled buttons, success states and mistakes.
I like mapping those states before build. Not as a huge document, but as a practical list of what the form needs to handle. If an email address is invalid, where does the message appear? Is it linked to the field? Does the visitor know what to correct? Can they submit using only a keyboard?
<label for="email">Email address</label>
<input id="email" name="email" type="email" aria-describedby="email-error" required>
<p id="email-error">Enter an email address we can reply to.</p>The code is simple, but the decision behind it needs to happen early. A form is not only a set of fields. It is a conversation with someone who may make mistakes, use assistive technology or be under pressure while trying to complete a task.
Designing Focus, Not Just Hover
A lot of interface design still pays more attention to hover than focus. That makes sense visually because hover states are easy to demonstrate with a mouse, but keyboard focus is just as important. If a button has a carefully designed hover style and a barely visible focus style, the interface is telling some users that their method of navigation was considered later.
I try to design focus states as part of the component, not as a browser default I hope will be good enough. That does not mean removing the browser outline and replacing it with something weaker. It means making focus visible, consistent and appropriate to the design.
This also affects motion. If an interaction uses animation, I need to think about reduced motion preferences early. The design should not depend entirely on movement to explain what happened. Motion can support understanding, but it should not be the only signal.
Accessibility As Part Of The Brief
The more I work on this, the more I think accessibility belongs in the brief. Not as a vague statement that the site should be accessible, but as practical expectations around navigation, forms, content structure, colour contrast, keyboard use and editor behaviour. That gives the project a better starting point.
It also makes trade-offs easier to discuss. If a visual idea creates a usability problem, it is better to know that early. The conversation is much healthier when accessibility is part of the design process rather than something used later to reject work that has already been invested in.
Retrospective Thoughts
Retrospectively, I think the strongest accessibility work happens before the component exists. Once the component has been designed, built and filled with content, the available fixes become narrower. Early decisions give the work more room.
That does not mean every project will be perfect. It does mean the important questions are asked while they can still shape the outcome. For me, that is the difference between treating accessibility as a checklist and treating it as part of how the website is designed in the first place.