The accessibility pass that happens during review, not after it
Pogpin audits the page you are already reviewing — missing alt text, unnamed controls, unlabelled fields, empty headings, tap targets under 24 × 24 px and horizontal overflow — and warns about contrast while you change a colour.
Accessibility work usually arrives as a PDF. Someone runs a scanner, exports 140 findings, and the report lands in a backlog where it competes with feature work. Half of it is noise, the important half is indistinguishable from the noise, and the whole thing is dated the moment the next deploy lands.
The problem is not the checks. It is the shape: an audit is a separate artefact, produced at a separate time, by a separate person.
Pogpin’s version runs inside the review you were doing anyway.
The tree, filtered down to what is broken
The widget lists the page’s DOM as a tree of elements, with a filter row above it:
- All — the whole tree
- Changed — only what this visual branch touched
- Issues — everything with a finding
- A11y — accessibility findings only
- Layout — layout findings only
Flip to Issues and the page collapses from a thousand nodes to the handful that are wrong. The panel steps between them one at a time, so an audit is a short walk instead of a hunt.
What it checks
Six checks, each phrased as the problem rather than a rule reference:
| Finding | What it means in practice |
|---|---|
| Image has no alt attribute | A screen reader reads a filename, or nothing |
| Interactive element has no accessible name | A button exists but cannot be announced or targeted |
| Form control has no accessible label | The field is unusable without sighted guessing |
| Heading is empty | The document outline has a hole in it |
| Interactive target is smaller than 24 × 24 px | Anyone with imprecise aim misses it |
| Element causes horizontal overflow | The page scrolls sideways on a phone |
That last one is worth the whole feature on its own. Horizontal overflow is the classic “it looks broken on my phone” report, it is almost always a single element, and finding it by bisecting CSS is a bad afternoon.
Contrast is checked while you change the colour
The other half runs during editing rather than inspection. Recolour text in a visual branch and the panel answers immediately: Contrast 3.1:1 — below the 4.5:1 this text size needs. The required ratio follows the text size, so large display type is held to 3:1 and body copy to 4.5:1.
Two layout warnings work the same way — the content no longer fits this element, and this element now sticks out past the page — so a spacing fix cannot quietly create the bug it was supposed to prevent.
Why the timing matters more than the checks
Every one of these findings is detectable by a dozen tools. What changes here is when you see it:
- During review, so the finding is attached to a page someone is already looking at.
- Next to a fix, so a missing label can be added in the branch and handed over as CSS or a task instead of filed as a ticket.
- Against the real rendered page, including states and widths you switched to, not a crawl of the markup.
- Continuously, because your reviewers open the page every week anyway.
A workable habit
- Run the Issues filter once before you call a page done.
- Fix what is fixable on the spot; pin the rest — a pin carries the selector, the browser and the viewport with it.
- Re-run it after a round of visual changes. A spacing edit is the most common way a tap target drops under 24 × 24 px.
The full walkthrough is in audit accessibility and layout while you review. And if you want the fixing half, see edit the live page with visual branches.