The WHO estimates one in six people live with a significant disability. For the web that isn't an edge case, it's a sixth of every audience you will ever ship to. And most of what gets in their way is invisible to the person who built the page, because you built it with your eyes, your ears, and your motor control.
I've spent few weeks building pour, a free accessibility suite that lives in your browser. It's named after WCAG's four principles (Perceivable, Operable, Understandable, Robust), and the logo is four squares whose negative space forms a plus. This post is what it does and, just as importantly, what it refuses to pretend it can do.
See your site the way someone else does
Reading "ensure sufficient contrast" changes nothing. Watching your own pricing page lose its green CTA to deuteranopia changes how you pick colors forever.
pour ships 49 vision, sensory, and motor simulations you can apply to any live page: color-vision deficiencies, cataracts, glaucoma, tunnel vision, low light, screen glare, motion sensitivity, reading stress, tremor, and more. They run as real filters over the real page, so you can scroll, hover, and use your site while inside someone else's experience of it.
An audit that doesn't bluff
Automated accessibility testing has an open secret: most of WCAG cannot be proven by a machine. Plenty of tooling responds by overstating. I built pour to do the opposite.
The engine has 74 automated rules; a default WCAG 2.2 AA audit runs 50 of them. Rules assist with success criteria, they never fully cover them, and pour says so out loud. Anything the engine can measure but cannot judge lands in a review lane for a human instead of being silently dropped or, worse, stamped as a pass. The report also ships a checklist of all 55 in-scope success criteria, so the parts only a person can verify stay visible instead of vanishing behind a green tick.
The philosophy in one line: if it can't be proven, it's a question, not a verdict.
From finding to fix without leaving the page
Every finding shows the affected element, why it fails in plain language, and how to fix it. Click a finding and pour highlights the element on the page; in the DevTools panel it can drop you straight onto the node. Contrast failures deep-link to a checker prefilled with the exact failing colors, so the "what do I change it to?" step takes seconds.
And when you've fixed everything, the all-clear actually means something: "no violations found" always comes with how many rules were checked and what still needs human eyes.
Private by design
Everything runs locally. No accounts, no analytics, no network requests, nothing leaves your machine. It's a non-profit initiative: no tiers, no upsell. The engine is open source (MIT) if you want to read how any rule decides.
Try it in the next 60 seconds
- Chrome / Edge: grab pour DevTools from the Chrome Web Store, open DevTools, find the pour tab.
- No install at all: drag the bookmarklet from pour.dev to your bookmarks bar and click it on any page.
- Firefox: submitted and in review. Safari: working, store release on the way.
Then run it on the page you're proudest of. If the review lane asks you a question you can't answer, that's the feature working.
I'd genuinely love feedback, especially from screen-reader users and anyone doing WCAG work professionally: what would make this useful enough to live in your daily loop? Comments open.
Top comments (0)