What accessibility audits actually find
Contrast ratios are the easy part. The findings that take real work are keyboard traps, focus order and forms that only make sense visually.
Teams expect an accessibility audit to be about colour. Contrast is genuinely the most common finding by count, and it is also the cheapest to fix — usually a handful of token changes in one afternoon.
The findings that cost real time are structural. A modal that traps keyboard focus. A custom dropdown that a screen reader announces as a div. A form where the only indication a field failed validation is that it turned red.
Focus order is the one almost everyone gets wrong, because it is invisible unless you test for it. If your visual layout puts the primary action first but the DOM puts it last, keyboard users experience a different interface from the one you designed.
The other systemic issue is error messaging written for people who can see the whole form. 'Please correct the highlighted fields' is useless if you cannot perceive highlighting. Errors need to be associated with their input programmatically and phrased so they stand alone.
We now run automated checks in CI and treat them as a floor rather than a result. Automation catches perhaps a third of real issues; the rest needs a person with a keyboard and a screen reader. Budget for that, because in most of our markets this is now a legal requirement rather than a nice-to-have.