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.

npm install -g pour-cli

Your first audit, in four steps.

From installing pour to checking your first fix. Start with a page you want to make more accessible.

1. Install the extension

   Add pour to Chrome, Edge or Firefox. It is free, and ready to use on the pages you visit.

2. 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.

3. 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.

4. 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.

What pour stands for.

The four principles of WCAG give pour its name. They describe what people need to use a website.

• Perceivable

  Make content available in ways people can perceive, with readable text, image descriptions and video captions.

• Operable

  Make navigation and controls work with a keyboard, a switch or a pointer.

• Understandable

  Use clear language, predictable behaviour and helpful instructions when something goes wrong.

• Robust

  Use markup that browsers and assistive technologies, including screen readers, can interpret reliably.

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.

• 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.

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.

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.

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.

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.

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 agent
npx skills add pourdev/pour-cli # the skill for coding agents

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.

Contrast checker

Enter text and background colours to see their contrast ratio, a live preview and how the pair measures against WCAG contrast requirements.

Coverage, in plain numbers.

86 success criteria in WCAG 2.2.

99 automated rules in pour engine.

94.6% of the top sites have proven accessibility failures.

The heaviest page tested, run by both engines.

The largest page tested is a technical specification with 194,000 elements. 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.

No automated tool can fully test a single WCAG criterion. This one included. pour engine is built directly on the spec: 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.

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.