// Letters — No. 001 — — Seattle — 1 min read
The accessibility reckoning
Why accessibility overlays failed the people they were sold to protect, and why I wanted fixes to happen in the code.
For a few years, a lot of companies sold accessibility as something you could install. Add one line of code, the pitch went, and an overlay would make your site ADA compliant, keep lawsuits away and spare you the work. Business owners bought it because it was cheap and it sounded official.
The overlay sat on top of the site and left the broken markup underneath it. So the people it was supposed to help, a student opening coursework, someone sending a job application, a parent ordering groceries, ran into the same broken widgets as before, with a toolbar in the corner.
Owners thought they were covered. Plenty of them were still breaking accessibility law, and some found out from a lawsuit.
Fixing it where the problem is
I built Auditvia because I wanted the fixes to happen in the code. It scanned a site’s code, opened pull requests that fixed issues at the source, and kept audit logs meant to hold up in a compliance review. It had no overlay.
Most of those fixes are ordinary engineering: a label on a form field, enough contrast to read the text, a button you can reach with a keyboard. They have to be made in the codebase by someone who knows the page, which is the exact part an overlay promised you could skip.
I think of accessibility as a human right. The web was meant to work for everyone who uses it, and that means fixing the code rather than covering it.