Make the web work for everyone
One in six people (opens in a new tab) experience the web differently than you think. pour shows you what’s getting in the way, and exactly how to fix it.
npm install -g pour-cli
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 (opens in a new tab) pour runs from iOS's share sheet on any page.
Your first audit, in four steps.
From installing pour to checking your first fix. Start with a page you want to make more accessible.
-
Install the extension
Add pour to Chrome, Edge or Firefox. It is free, and ready to use on the pages you visit.
-
Open pour and audit
Visit the page you want to check, open pour from the browser toolbar, and run an audit. You can also use the pour panel in DevTools.
-
Read the findings
See which elements need attention, why they matter, and how to fix them. Findings marked for review need a person to check.
-
Fix it. Check again.
Make the changes in your code, reload the page, and run another audit. Then try the simulations and check the page with a keyboard.
Explore accessibility simulations.
See how changes in vision, perception and movement can affect the way a site looks and works. Pour includes 55+ simulations and lenses. Each one stands in for a problem a page can have, not for what any person sees, hears or feels: every condition is a range, and each figure counts people at every degree of it. Try a selection on this page, from clouded vision to keyboard tab order. Press one to apply it, then press it again or Escape to clear.
Try this page with:
Nothing is running. Press one above and this box will say what just changed, in the product’s own words.
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.
What pour stands for.
The four principles of WCAG give pour its name. They describe what people need to use a website.
-
Perceivable (opens in a new tab)
Make content available in ways people can perceive, with readable text, image descriptions and video captions.
29 WCAG criteria
-
Operable (opens in a new tab)
Make navigation and controls work with a keyboard, a switch or a pointer.
34 WCAG criteria
-
Understandable (opens in a new tab)
Use clear language, predictable behaviour and helpful instructions when something goes wrong.
21 WCAG criteria
-
Robust (opens in a new tab)
Use markup that browsers and assistive technologies, including screen readers, can interpret reliably.
2 WCAG criteria
pour for Meta QuestOut now
See your own room the way it can fail someone.
The first pour app outside the browser. Put on a Meta Quest 3 or 3S and the simulations are drawn over the room in front of you: the kitchen, the office, the sign on the door.
Get it on the Meta Horizon Store (opens in a new tab)
For Meta Quest 3 and 3S. Free, like every pour tool.
-
The room, not a screenshot
Each simulation is drawn live over the headset’s view of the room and moves as the head turns. Blur follows distance: near-vision loss softens what is close, short sight what is far.
-
The same simulations
Colour vision, field loss, clouded lens, focus and more. Each one says what it is and how many people it touches, and most can be set to mild, moderate or severe.
-
Nothing leaves the headset
The app holds no network and no microphone permission. Camera images are used for the frame being drawn, then discarded. Educational: not a medical device, and it diagnoses nothing.
Photograph: Roy.wonder.cohen (opens in a new tab), CC BY-SA 4.0 (opens in a new tab), shown in monochrome.
Five tools. All free.
Check accessibility in your browser, editor or terminal. No accounts, no subscriptions, no paid tiers.
Find the issue.
Understand the fix.
The pour browser extension checks the page you’re working on and puts the affected element, the reason it fails and guidance for fixing it in one place.
Free for Chrome, Edge and Firefox. No account needed. Audits run locally, and results stay in your browser.
- Know what needs attention
- Findings are grouped by severity, with the affected markup and links to the relevant guidance. Items that need human judgement appear as review findings.
- Go straight to the element
- Highlight a finding on the page, or inspect it in DevTools. See the issue in context while you work on the fix.
- Test more than appearance
- Explore 55+ simulations and lenses, including vision effects, keyboard tab order, and a map of landmarks and headings. Try some examples on this page.
- Choose what to check
- Select the WCAG standard and level for your project. Enable optional best-practice checks when you need them.
- Keep results beside your work
- Open the full audit in DevTools or the side panel, or use the toolbar popup for a quick summary. Results stay with each tab.
- Share the next step
- Copy a finding as a ticket, or export results as Markdown, CSV or JSON so the details can travel with the work.
Bookmarklet
No install needed
Drag to your bookmarks bar, then select it on any page.
The same pour engine audit runs right there, in an on-page panel, entirely in your browser.
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 (opens in a new tab); 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.
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.
Command line
For terminals, CI and agents
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 55+ simulations, so a design review can see the page the way your visitors do. It speaks the Model Context Protocol as well: pour mcp hands an AI agent the audit, the keyboard focus order of a page and the screenshot, so the agent checks its own work in a real browser instead of guessing from the source.
Need a site-wide report? pour follows internal links, audits the pages it finds and generates a standalone HTML accessibility report. Watch progress in your browser, and rerun the same command to resume an interrupted audit.
npm install -g pour-cli
pour yoursite.com # audit; exit 1 if findings
pour index.html # a page on disk, assets and all
pour report yoursite.com # crawl the site and generate an HTML report
pour yoursite.com --filter deuteranopia # screenshot through a simulation
pour --filter list # all 55+ simulations
pour mcp # serve the tools to an AI agentFree and open source, like the engine: on npm (opens in a new tab) and on GitHub (opens in a new tab). It drives the Chrome you already have, so installing it never downloads a browser.
Editor extension
For VS Code
An extension for VS Code reads your HTML, React, Vue, Svelte and Angular files, and your Liquid and Nunjucks templates, as you type and runs the pour engine rules over them. Each problem sits on the tag that caused it, with the line to write instead, in the Problems panel and beside the line number. Nothing leaves your machine.
An editor can only read the code. Colour contrast, tap target size, focus and motion need the page on screen, so those checks stay with the browser tools. Anything a script builds, or a value that comes from code like alt={name}, is left alone rather than guessed at, and the status bar says how many were skipped.
Contrast checker
Check a colour pair
Enter text and background colours to see their contrast ratio, a live preview and how the pair measures against WCAG contrast requirements. Use hex, RGB or modern CSS colour formats such as OKLCH.
If the pair falls short, explore suggested adjustments and copy the colour values back into your stylesheet. Everything is calculated in your browser using the same contrast maths as pour engine.
Build with pour engine
Use the accessibility engine directly in your own projects.
npm install pour-engineCoverage, in plain numbers.
Each unit below stands for one thing, drawn once, at one size. Filled means counted in; outlined means counted out. The caption says exactly what each row counts.
86success criteria in WCAG 2.2
Each square is one success criterion. 51 filled: pour engine assists on them. 35 outlined: criteria that still need a human. The audit hands you that checklist rather than leaving it out.
99automated rules in pour engine
Each square is one rule. All 99 ship in the browser extension, the bookmarklet and the command line. The editor extension runs the checks that can be assessed from source code. 78 map to a published criterion; the other 21 are best practice, labelled as such.
94.9%of the top sites have proven accessibility failures
Each glyph is one site in a hundred. 95 are filled, the nearest whole glyph to 94.9%, measured across 50,890 pages in September 2026.
The heaviest page tested, run by both engines.
The largest page tested is a technical specification with 194,000 elements. Play the recorded benchmark results at 30× speed. The animation uses the recorded median times.
0:00Benchmark time · 30× playback
24 times faster on this page, timed in September 2026 over three runs with the middle result kept. On a typical page the gap is three times. Fast enough to run on every change without noticing.
Honest about what a tool can see.
Every rule in pour engine comes from reading WCAG 2.2 itself.
- Success criteria in WCAG 2.2
- 86success criteria in WCAG 2.2
- Automated rules in pour engine
- 99automated rules in pour engine
- Criteria that still need a human
- 35criteria that still need a human. We hand you the checklist
- Speed on a typical page
- 3×faster than axe-core® on a typical page, timed on 138 real websites
- Speed on the largest page
- 24×faster on the largest page tested, a technical specification with 194,000 elements
- Accuracy on Beta Block
- 38of 38planted faults detected on Beta Block, counted against its answer key
No automated tool can fully test a single WCAG criterion. This one included. pour engine is built directly on the spec (opens in a new tab): its rules assist on 51 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 is settled by reading the spec.
It is fast. In September 2026 it was timed 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, three times faster, and the gap narrows a little on the heaviest pages. On the largest page tested, a technical specification with 194,000 elements, it is 24 times faster, done in seven seconds where axe-core® takes two minutes 43 seconds.
It is accurate, and that can be shown. Accuracy can only be measured where the right answers are already known, so Beta Block exists: a fictional gym website with 38 real accessibility problems planted in it and 8 things that need a person’s judgement, published with the answer key so any tool can be marked against it. pour engine finds all 38 problems, flags all 8 judgement calls, and reports nothing that is not there. This counts planted faults, not individual audit findings: one fault can affect several elements or trigger more than one check, so the extension can show a higher total. It is one page, and it was written here, so treat it as a like-for-like test rather than a universal score.
The engine is open source: on npm (opens in a new tab) and on GitHub (opens in a new tab).
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 pour’s own measurements, September 2026, method described above.
Non-profit, by design.
Every tool is free to use: no accounts, no subscriptions, no paid tiers, ever. Accessibility tooling shouldn’t be gatekept. Donations are welcome; payment never is.
The right thing is now also the required thing.
Accessible sites were always better sites. Now they are also what the law expects. No fear-marketing needed, just the dates.
| Regulation | Who | Where it stands |
|---|---|---|
| European Accessibility Act (opens in a new tab) | Companies serving EU consumers | In force since 28 June 2025, with per-country penalties. Its technical standard, EN 301 549 (opens in a new tab), was reissued in September 2026 and now points websites at WCAG 2.2 AA |
| ADA Title II (US) (opens in a new tab) | State and local government services | WCAG 2.1 AA required by 26 April 2027 for larger entities, 2028 for smaller |
| WCAG 2.2 (opens in a new tab) | The standard the laws point at | The current W3C recommendation, and exactly what pour tests |