We used to treat accessibility as a final checklist — a round of fixes before launch. It never worked. Fixing accessibility after the fact is like painting over structural cracks. The surface looks fine until someone leans on it.
In March we overhauled our process. Accessibility is now built into every stage, from design to deployment.
The shift starts in design
Our designers now work with contrast checkers open from the first mockup. Every interactive element is annotated with its expected keyboard behavior. Focus order is mapped in the wireframe, not discovered during QA.
This changed the designs themselves. Buttons got more generous padding. Form labels moved from placeholders to visible labels above fields. Hover-only interactions were replaced with states that work on touch and keyboard alike.
Semantic HTML is the foundation
Most accessibility problems disappear when you use the right HTML elements. A <button> handles keyboard events, focus management, and screen reader announcements without a single line of JavaScript. A <div> with an onClick handler does none of those things.
We run an automated check in our linter that flags interactive <div> and <span> elements. It catches the most common mistake before it reaches a browser.
The testing stack
Automated tools find roughly thirty percent of accessibility issues. They catch missing alt text, insufficient contrast, unlabeled form controls, and broken ARIA references. We run axe-core in our CI pipeline on every pull request.
The other seventy percent requires manual testing. We tab through every page. We test with VoiceOver and NVDA. We resize to 400% zoom and check that nothing breaks.
Once a month — starting this March — one team member spends a full day using the project with only a keyboard. No mouse. It is the single most revealing test we have found.
Common mistakes we fixed
Carousels without pause controls. Auto-advancing content causes problems for screen reader users and people with cognitive disabilities. Every carousel now has visible pause and navigation controls.
Modals that trap focus incorrectly. When a modal opens, focus should move to it. When it closes, focus should return to the element that triggered it. We had three projects where closing a modal sent focus to the top of the page.
Images with meaningless alt text. “Image” and “photo” are not descriptions. “Team meeting in a sun-lit office with five people around a whiteboard” is. If an image is decorative, it gets an empty alt="" to be skipped entirely.
The business case
Accessible websites work better for everyone. Clear labels help all users. Keyboard navigation helps power users. Proper heading structure helps SEO. Sufficient contrast helps anyone using a screen in sunlight.
One client saw a twelve percent increase in form completions after we fixed label associations and error messaging. Accessibility is not charity. It is good engineering.
We will not ship a project that fails WCAG 2.1 AA. That is the new baseline at Kotito — not a feature request, not a nice-to-have, and not a phase two item. It ships accessible or it does not ship.
