My first instinct was to try to cover as much ground as possible, cover as much WCAGs as I could, but the more checks I tried to add, the more the tool started to need the same accessibility expertise it was meant to replace. Some issues genuinely require context and judgment to flag well; cramming those in would have made the tool robust in a way that worked against its actual purpose. This started as a hackathon project, so I was working with a hard time limit.

I scoped it down to four checks: missing alt text, unlabeled form inputs, missing page structure (a <main> landmark), and a basic contrast conflict. I chose these specifically because they’re high-frequency, low-complexity, and immediately understandable. A developer with zero accessibility background can read a flag and know exactly what’s wrong and where.

That same instinct shaped the tone. Accessibility feedback is usually dense and technical, which is part of why the same issues keep slipping through. I wrote each flag to be playful instead: “Missing Alt Text: Why is this img so secret? 🤭”, instead of a formal violation notice. A developer would actually read it and act on it, rather than skim past another compliance warning. Sometimes, we just need a lil something cutesy and fun in the midst of all these dark screens!

A few things I’m proud of under the hood:

• Click-to-locate. Every flagged issue in the popup is clickable, clicking it scrolls the page directly to the problem element and highlights it with a soft red glow, so a developer doesn’t have to hunt for what’s broken.

• Deduplication. The scanner groups repeat issues instead of listing the same warning fifty times on a page with fifty broken images, the popup stays readable no matter how messy the page is.

• Re-injection safety. The content script checks whether it’s already running before initializing again, avoiding duplicate scans if the extension gets triggered twice on the same page.