Make the web work for everyone
One in six people experience the web differently than you think. pour shows you what's getting in the way, and exactly how to fix it.
Bookmarklet - no install needed. Audit with pour drag me to your bookmarks bar No bookmarks bar? Press Cmd+Shift+B or Ctrl+Shift+B to show it, then drag the button onto it. There's a bookmarklet too: drag it to your bookmarks bar next time you're at your computer. Add the pour shortcut pour runs from iOS's share sheet on any page.
How pour works
-
Built on the spec
Every rule in pour engine comes from reading WCAG 2.2 itself.
-
Lives where you work
A DevTools panel, a bookmarklet, and a terminal command for CI. Findings point at the element and show the line to write instead.
-
Non-profit, by design
Every tool is free: no accounts, no subscriptions, no paid tiers. Accessibility tooling shouldn't be gatekept.
Every sense
How will your site work for senses that aren't yours?
Every visitor brings their own senses to your interface. Design for all of them, and the site gets better for everyone.
What a screen reader finds
Hear the difference a few lines make.
Missing alt text, a link that only says click here,
unnamed buttons, unlabeled fields, a table whose columns never
say what they hold: five small gaps with a loud result, and a rule
that points at each one and shows the line to write instead.
Voiced by your browser's built-in speech. Real screen readers have their own voices, speeds, and verbosity.
Vision, sensory & motor simulations
Borrow someone else's eyes and hands.
pour tools ship 50+ simulations that show any page the way someone else meets it. The extension and the bookmarklet each carry the full set, one press away while you build, and the command line saves any of them as a screenshot.
Try this page with:
Every colour just left this page. Could you tell? Run the same simulation on a site where red means error and green means paid, and the meaning goes with the colour.
Press it again, or Escape, to clear. The tunnel, the blank spot and the ring follow your pointer, as they do in the extension.
Not a party trick, a ten-second check. Can't find the primary button under Clouded lens? Its contrast is too low. Lose your place under Tunnel vision? Your layout leans on peripheral sight. Miss the close button under Hand tremor? Your target is too small.
- 27 vision simulations
- Seven kinds of color vision on research color matrices, plus glaucoma, macular degeneration, cataracts, field loss, blur, low light, and coloured-overlay tints. The tunnel and central-loss overlays follow your pointer across the page.
- 16 sensory & cognitive simulations
- Sensory overload, attention and focus, processing differences, and five reading simulations for dyslexia: crowding, tracking loss, letter instability, pattern glare, and contrast sensitivity.
- 6 motor simulations
- Essential tremor at two strengths, resting tremor, ataxic drift, sudden involuntary jerks, and a hidden pointer that leaves you with the keyboard. These move the cursor, not the page: small targets and hover-only controls fail here first.
The colour-vision matrices come from the research of Brettel, Viénot & Mollon (1997) and Machado, Oliveira & Fernandes (2009), as compiled by DaltonLens.
The four principles
Four promises, straight from the spec.
WCAG 2.2 organizes all 86 of its success criteria under four principles: Perceivable, Operable, Understandable, and Robust. POUR is where pour gets its name, and how the whole suite is organized. Read the principles from your user's side and they're promises:
-
“I can perceive it.”
Text I can read, images that speak, video I can follow, whatever senses I bring.
-
“I can operate it.”
Everything works with my keyboard and my switch, with targets big enough to hit.
-
“I understand it.”
Fields say what they want, errors say how to recover, nothing shifts under my feet.
-
“My tech works with it.”
My screen reader, browser, and settings all get the truth from your markup.
pour tools
Understanding lives where you already work: DevTools.
Audit any page as you build it. The full report sits in a DevTools panel, a summary in the toolbar popup, and all 50+ vision, sensory and motor simulations are available in each. Results are stored per tab and stay live.
- Per-element findings
- The offending markup, why it matters to real users, how to fix it, and a link to the rule's documentation.
- Show me
- One press scrolls the element into view and flashes it on the page.
- WCAG your way
- Version and level selection, 2.2 by default. Best-practice rules are opt-in, including checks for accessibility that should be removed.
Your first audit, in three steps
-
Install it, then open the page you're working on
Any page, including
localhost. Nothing is sent anywhere: the audit runs in your browser and the results never leave it. -
Open DevTools and pick the pour tab
Cmd+Option+I or F12, then find pour in the row of DevTools tabs next to Elements and Console. The toolbar icon gives you the summary; the panel is where the full report lives.
-
Press Run audit and read the first finding
Results arrive grouped by rule, most critical first. Each finding names the element, quotes the offending markup, says who it hurts and why, and gives you the line to write instead. Show me scrolls to the element and flashes it on the page.
Never done this before? Alt text, contrast, and form labels are most of what any first audit finds, and each is usually a one-line fix. Every finding explains itself, and links to the criterion it came from when you want the source.
No install needed
Try it now: the bookmarklet.
Drag the button below to your bookmarks bar, then press it on any page. The same pour engine audit runs right there, in an on-page panel, entirely in your browser. Or just click it to audit this page.
Audit with pour drag me to your bookmarks bar
The bookmarklet is a desktop tool: open this page on your computer to drag it to your bookmarks bar.
On iPhone and iPad the bookmarklet rides Safari's share sheet as a shortcut instead: the same audit, in the same on-page panel.
Add the pour shortcut- Tap the button; the Shortcuts app opens and asks to add pour.
- In the Settings app, under Shortcuts, then Advanced, turn on Allow Running Scripts.
- On any page in Safari, open the share sheet and tap pour.
Prefer a file? Download the shortcut and open it from your downloads.
Fair warning: sites with a strict Content-Security-Policy can block any bookmarklet, and cross-origin frames stay out of reach. The extension has neither limit.
For terminals and CI
The same audit, as a command.
One install puts pour in your terminal. Point it at a
URL and the same pour engine audit runs in headless Chrome and
reports to stdout, with exit codes that make it a CI gate out of
the box. It takes screenshots too, through any of the 50+
simulations, so a design review can see the page the
way your visitors do.
npm install -g pour-cli
pour yoursite.com # audit; exit 1 if findings
pour yoursite.com --filter deuteranopia # screenshot through a simulation
pour --filter list # all 50+ simulationsFree and open source, like the engine: on npm and on GitHub. It drives the Chrome you already have, so installing it never downloads a browser.
86 success criteria in WCAG 2.2
86 automated rules in pour engine
48 criteria that still need a human. We hand you the checklist
pour engine
Honest about what a tool can see.
No automated tool can fully test a single WCAG criterion. This one included. pour engine is an engine built directly on the spec: its rules assist on 38 of the 86 criteria and claim to settle none of them, every finding explains itself in plain language, and every audit ships the complete manual-review checklist for your chosen version and level alongside the findings. Nothing silently skipped, and when a judgment call comes up it's settled by reading the spec.
It's fast. In August 2026 we timed it on 138 real websites against axe-core®, the checker most accessibility tools are built on, running each three times and keeping the middle result. On a typical page pour engine finishes in a fraction of a second, more than three times faster, and the bigger the page the bigger the gap: seventeen times faster on the largest page we test, a technical specification with 190,000 elements. Fast enough to run on every change without noticing.
On the 138 real websites it found more problems than axe-core® on 42 pages, fewer on 19 and the same on 77; on the two most common problems of all, images with no description and links with no name, the two agree to the element. And when it cannot be sure, it doesn't guess: it hands you the question, with the exact words of the standard, instead of a verdict either way.
It's accurate, and we can show it. Accuracy can only be measured where the right answers are already known, so we built Beta Block, a fictional gym website with 37 real accessibility problems planted in it and 8 things that need a person's judgement, and published the answer key so any tool can be marked against it. pour engine finds all 37 problems, flags all 8 judgement calls, and reports nothing that isn't there. axe-core® finds 28 of the 37 (31 if you count the ones it only marks as “maybe”) and none of the 8. It is one page, and we wrote it, so treat it as a like-for-like test rather than a universal score.
It's strict on purpose. Every rule is exercised against annotated testbeds and a pixel-measurement lab before it ships, so when a finding feels too strict, it's quoting the spec.
The engine is open source: on npm, on GitHub, and documented here.
axe® and axe-core® are registered trademarks of Deque Systems, Inc., which is not affiliated with and does not endorse pour. The comparison figures are our own measurements, August 2026, method described above.
Beta What the badge means
Everything here ships today: the 86 rules, the manual checklist, the extension, the bookmarklet, the command line. Beta is about maturity, not completeness. The rule set is still growing, thresholds are still being tuned, and the engine keeps being tested and refined, release by release.
So a finding can still be wrong. When you think a call is genuinely wrong, send it to us with the page and the rule: we adjudicate against the spec text, and reports like that are exactly how the engine gets accurate. The badge comes off when they stop finding things.
Non-profit, by design.
Every tool is free to use: no subscriptions, no paid tiers, ever. Donations are welcome; payment never is.
DonateFor organizations
The right thing is now also the required thing.
Accessible sites were always better sites. Now they're also what the law expects. No fear-marketing needed, just the dates:
| Regulation | Who | Where it stands |
|---|---|---|
| European Accessibility Act | Companies serving EU consumers | In force since 28 June 2025; enforcement has begun, with per-country penalties |
| ADA Title II (US) | State & local government services | WCAG 2.1 AA required by 26 April 2027 (larger entities) / 2028 (smaller) |
| WCAG 2.2 | The standard the laws point at | The current W3C recommendation, and exactly what pour tests |
The WebAIM Million finds detectable WCAG failures on roughly 95% of the world's top homepages, year after year. Mostly alt text, contrast, and labels: your team can fix those this sprint.
Rolling pour tools out across a team, or need a question answered before you can adopt it? Write to info@pour.dev. A person answers, not a pipeline.