Accessibility is not a launch task
Contrast, focus states and keyboard paths were in the first components we built. Here is what that cost, and what retrofitting them would have cost instead.
Contrast ratios, focus states and keyboard paths were in the first components we built, before there were pages to put them on. This is a post about what that cost, which is the part usually left out.
It cost time, early, when time felt scarcest. Every component took longer. Deciding that muted text had to clear four and a half to one against its background eliminated several palettes we liked. The focus ring went through four versions because the first three looked like a mistake on a pale surface.
What it bought is harder to see, because it is an absence. There is no retrofit backlog. Nobody is going to open a ticket that says make the whole site keyboard navigable, which is the kind of ticket that does not get picked up because it cannot be finished in a sprint and cannot be shown off when it is.
The second thing it bought was less obvious. Constraints that seemed to be about accessibility turned out to be about quality generally. A minimum touch target size makes a control easier to hit with a mouse too. Text that clears a contrast ratio is easier to read at night. A visible focus ring tells everyone where they are.
The honest version: we still get it wrong. We shipped a header that overflows its container at tablet widths and did not notice for weeks, because we tested at phone and desktop and assumed the middle would follow. Building it in from the start is not the same as getting it right, it just means the fixes are small.