Last weekend I had the chance to speak at the Latin Heritage Month Innovation Summit, and I brought a topic I care a lot about: web accessibility, viewed through the lens of the Pareto Principle.
Most people know the 80/20 rule from economics — Vilfredo Pareto observed that in 1896 Italy, roughly 80% of the land was held by 20% of the population. I opened the talk with that map, then flipped it: what if we looked at our own codebases the same way? Instead of one country’s land ownership, imagine a wireframe of the modern web — and instead of chasing every possible accessibility issue, we go hunting for the vital few bugs that cause the vast majority of the friction.
To make the point land (and to have a little fun with it), I opened the talk with a rap I generated — a genuinely goofy way to get a room full of developers laughing before diving into WCAG categories.
The data behind the pitch
I leaned heavily on WebAIM’s Million report, which audits the accessibility of the top 1,000,000 home pages on the web. The numbers make the case better than I ever could: pages average 56 detected errors each, and 96% of all 56 million errors fall into just six categories:
- Low contrast text — 83.9% of pages
- Missing alt text — 53.1%
- Missing form labels — 51%
- Empty links — 46.3%
- Empty buttons — 30.6%
- Missing document language — 13.5%
That’s the “vital few.” Low contrast is trivially solvable — five seconds with a free contrast checker — so I told the room we’d spend our real focus time on the other five: keyboard and screen reader access, which is where most sites actually fail real users.
The fixes we walked through
- Alt text — the “what sentence would replace this image if it vanished” test.
alt="image"tells a screen reader user nothing. - Headings — big, bold text is a font style, not structure. Screen reader users navigate page-to-page by heading level, so a page with no real
<h1>/<h2>hierarchy is invisible scaffolding. - Form labels — placeholder text disappears the moment you start typing, so it can’t do a label’s job. A field needs a real, persistent label.
- Interactivity — if it looks like a button, it needs to be a
<button>. A styled<div>with a click handler is invisible to a keyboard and silent to a screen reader. - Link text — “Click Here” and “Read More” mean nothing out of context, and screen reader users often navigate a page via a list of links alone (the VoiceOver/NVDA “rotor”). Link text has to make sense on its own.
I also called out something that felt important to say out loud in a room full of people building faster than ever with AI tools: AI generates what is common, not what is correct. If the average page has 56 errors, that’s exactly the pattern AI coding assistants have been trained on. Prompting for accessibility and manually auditing before you ship isn’t optional anymore — it’s the whole point of the talk.
Try it yourself: the 2-minute audit
You don’t need expensive software to catch most of this. Unplug your mouse, and tab through your own site with just a keyboard and your eyes. Can you reach every link, every button, every form field, in a sane order, and always see where focus is? That’s most of the audit right there.
cantclickthis.dev
To make all of this concrete, I built cantclickthis.dev — a small site walking through these exact issues with live, interactive examples, plus a checklist to run through before you ship. If you were in the room (or if you weren’t), it’s a good place to go poke at broken buttons on purpose and see why they’re broken.
The core message I wanted to leave people with: you don’t need to fix everything today. You just need to find the vital few. Twenty percent of the effort — one tool (a contrast checker) and one habit (tab through your site) — removes the vast majority of the friction for real users.