Anyone can unplug their mouse, pick up a keyboard, and tab through a homepage for five minutes. That part is not hard, and it is not what earns you the nod from the VP of Engineering across the table. What actually changes how people see you in that room is not the five minutes you spend testing. It is the three sentences you write immediately after it.
Most people who run a quick accessibility check stop at the finding itself. They screenshot a missing focus ring, drop it in Slack with "hey, found this," and move on to the next tab in their browser. Nobody remembers that message by the next standup. The people who get remembered as "the one who really thinks about this stuff" are doing something different with the exact same five minutes of raw data. They are turning an observation into a note a manager can act on without asking a single follow-up question.
The Stat: WCAG Success Criterion 2.1.1 Keyboard (Level A) and 2.4.7 Focus Visible (Level AA) can both be checked in minutes using nothing more than a keyboard, and both are among the common, real failures turned up in large-scale accessibility audits. (Source: W3C Web Accessibility Initiative, WCAG 2.1)
The Test Was Never the Impressive Part
If you have not run it yet, run the actual 5-minute keyboard test first, if you haven't - it walks through the mechanics: unplug the mouse, tab through the page, watch where focus goes and where it disappears. That is the raw material. This article picks up exactly where that one leaves off.
Here is the trap most people fall into. They run the test, find something real, and then present it like a bug report: "the focus outline is missing on the nav links." True, but flat. A junior contributor states facts. A senior one states consequences. The gap between those two sentences is the entire gap this article is about closing, and it takes about ninety seconds once you know the shape of it.
Pick One Finding, Not Five
Five minutes of tabbing through a page will usually surface more than one problem. A focus indicator that vanishes on the search button. A modal that traps keyboard focus and never lets go. A "skip to content" link that does not exist at all. Resist the urge to list all of them.
Walking into a meeting with a laundry list of five issues reads as noise. Walking in with the single worst one, explained precisely, reads as judgment. Judgment is the thing that gets you invited back to the next review. Pick the finding that is either the most common pattern on the page (repeated across every card or every form field) or the one that would fully block someone from completing the primary task. That is your one finding for this exercise.
The POUR Framework Is Your "Why It Matters" Generator
This is the part that actually separates the senior-sounding note from the flat one. WCAG is built around four principles: Perceivable, Operable, Understandable, and Robust - POUR for short. You do not need to cite the acronym out loud in the meeting. You need to borrow its logic to explain the consequence, not just the defect.
A missing focus indicator, for instance, is not just "a CSS thing." It is an Operable failure: a person navigating by keyboard alone, whether due to a motor impairment, a broken trackpad, or simply a preference for keyboard shortcuts, loses track of where they are on the page entirely. That is the sentence that makes a product manager sit up, because it is framed around a person failing to complete a task, not around a missing outline in the stylesheet.
This single move, translating "what is broken" into "which POUR principle it violates and who that hurts," is the exact language that reads as senior in a review. It signals you understand the standard behind the symptom, not just the symptom itself.
Three Sentences, Built the Same Way Every Time
Once you have your one finding and its POUR angle, the write-up is a fixed template:
- What it is. One plain sentence describing the observable problem. No jargon, no acronym soup.
- Why it matters. One sentence connecting it to a real task and a real principle (Perceivable, Operable, Understandable, or Robust).
- What to do. One sentence with a concrete, scoped next step - not "fix accessibility," but the specific change.
Here is what that looks like applied to a real, common pattern: a custom dropdown menu that loses visible focus when navigated with the arrow keys.
- What it is: "Tabbing into the account menu highlights the trigger, but pressing the arrow keys to move through the options gives no visible indicator of which item is focused."
- Why it matters: "This is a Level AA Focus Visible failure under WCAG 2.4.7 Focus Visible - anyone navigating by keyboard has no way to tell which menu item they are about to select."
- What to do: "Add a visible focus style to each menu item on
:focus, matching the outline already used on the primary nav links."
That is the whole note. It took less time to write than it took to find the bug in the first place, and it reads like it came from someone who has done a hundred of these before.
Weak Note vs. Senior Note, Side by Side
| Element | Weak version | Senior version |
|---|---|---|
| Framing | "Focus ring is missing on nav links" | "Keyboard users lose track of position in the nav" |
| Evidence | None cited | References the relevant WCAG success criterion |
| Scope | Vague, "fix accessibility" | One specific, testable change |
| Length | Rambling or a bare screenshot | Exactly three sentences |
| Underlying principle | WCAG 2.1.1 Keyboard not mentioned | Named explicitly, tied to a real user consequence |
Before You Hit Send
- I picked exactly one finding, not a list
- Sentence one states the observable fact, nothing more
- Sentence two names the affected task and, where useful, the specific success criterion
- Sentence three gives a scoped, concrete fix - not a general instruction
- I read it out loud once and cut anything that was not load-bearing
- I did not bury the note in a wall of screenshots
When Three Sentences Is Not Enough
This exercise is deliberately small. It is meant to build a habit and a reputation, not to replace real audit work. If the quick check turns up a pattern that repeats across dozens of components, or if leadership asks "how bad is this, really, across the whole site," three sentences will not carry that conversation. That is the moment to get a full, prioritized audit once you're ready to go deeper rather than trying to stretch a five-minute check further than it was built to go.
There is also a quieter version of this trap worth naming: using the three-sentence note as an excuse to stop looking. A five-minute pass is a sample, not a survey. It tells you that a problem exists and roughly how serious it feels in the moment, not how many places in the product share the same pattern. Treat the note as the opening move in a conversation, not the closing argument. The best outcome of a good three-sentence note is usually someone asking "does this happen anywhere else?" - and having a real answer ready for that question is what turns a one-off observation into an ongoing habit people trust.
The habit itself, though, costs you nothing extra. Every keyboard pass you already run at the start of a review can end in the same three-sentence structure, and over a few months that consistency is what actually gets noticed, one clear note at a time.
Once you are ready for the deeper version of this - the kind with full findings prioritized by severity and mapped to every relevant success criterion - you can turn your quick findings into a full, prioritized audit whenever the moment calls for it. And if you would rather just talk it through with a person first, the team at experts@wcag.world reads every message that comes in.