You found a button with gray-on-gray text that fails contrast, a form field with no visible label, and a modal that traps keyboard focus. Now you need to write it up so someone can fix it without coming back to ask which button on which page. A scattered list of complaints does not do that. A focused pass that records each problem next to the screen it lives on does.
Here is the full sequence, one issue at a time, ending in a single document you can hand off.
Step 1: Open a tab and start capturing the failing screen
Go to start a new review and click Capture screen. The browser asks which window or tab to share, and the current frame is drawn to a canvas. No install, no extension, no signup. If your IT setup blocks browser add-ons, that matters; this runs entirely in the page, which is the whole point of capturing screen feedback without an extension.
Outcome: you have a still of the exact screen that fails, at the exact size the user sees it.
Step 2: Crop to the element that fails
Drag a rectangle around the control in question, the low-contrast button or the unlabeled input, or keep the full frame if the problem is the whole layout reflowing at 200% zoom. Cropping is the only image edit, and that is fine for accessibility work. You are not drawing red circles; you are pointing at the thing and writing down what is wrong.
Outcome: each captured item shows one clear failure rather than a busy full page where the reviewer has to guess what you meant.
Step 3: Drop a pin and state the issue in plain terms
Add a numbered pin to the exact spot, the icon-only button with no accessible name, for instance. Then add a comment. Type it, or dictate it with the browser's built-in speech recognition in Chrome or Edge. Say what fails, why, and the standard it touches:
Pin 1: "Submit" button text is #9b9b9b on #d8d8d8. Contrast ratio is roughly 1.6:1. WCAG 2.1 AA needs 4.5:1 for body text. Darken the text or the button to pass.
Notice what that comment gives the receiver: the measured ratio, the threshold, and a direction for the fix. That is the difference between feedback that gets fixed and a vague "this is hard to read." The same care that makes screen feedback easy to act on applies here.
Step 4: Add issues that have no single screen
Some accessibility problems are not tied to one element. Tab order that jumps around, a focus indicator that never appears, a page with no skip link. For those, add a free-floating comment with no screenshot. Write the behavior and how to reproduce it: "Tab from the search box and focus lands on the footer, skipping the entire nav. Expected: focus moves to the first nav link."
Outcome: keyboard and focus problems get recorded alongside the visual ones, in the same document, instead of living in a separate email.
Step 5: Repeat the capture for every distinct failure
Each screenshot becomes its own item. Walk the page or flow and capture each problem as you hit it: contrast, missing labels, heading order, alt text gaps, focus traps. Do not batch ten issues into one comment. One item per failure keeps the eventual fix list clean, because the developer can resolve them one at a time.
If you are reviewing a build still under construction, the same pass works; this is close to capturing feedback as you walk a flow, just with accessibility as the lens.
Step 6: Publish and get a link the team can open
Click Publish. The review is saved and gets a short public URL of the form /r/<slug>. Anyone with the link can read it, no account needed on their end. You can publish with no account yourself; an anonymous review is kept for 30 days, and signing in afterward claims it permanently. The full accessibility review workflow is built around producing exactly this artifact.
Outcome: one link that holds every issue, each pinned to its screen, each with a stated fix.
Step 7: Send the format each receiver actually uses
The same review is available in more than one shape. A designer or PM opens the public link. A manager who wants a record gets a PDF or Word export. If a developer is handing the work to a coding agent, the markdown version at /r/<slug>/markdown is plain text the agent reads directly, which is how markdown bug reports reach a tool like Cursor without any reformatting.
| Receiver | Format |
|---|---|
| Designer, PM | Public review link |
| Stakeholder, audit record | PDF or Word export |
| Developer or coding agent | Markdown at /r/<slug>/markdown |
Step 8: Track replies and resolution on each issue
Anyone with the link can post a comment on any individual item, so a developer can ask "is this the desktop or mobile breakpoint?" right on the contrast issue rather than in a separate thread. As fixes land, mark each comment resolved. The owner analytics page shows visit counts and visitor geography, so you know the doc was actually opened.
One pass, one link, every failure pinned to its screen with a stated remedy. Start your accessibility review at the new review page and capture the first failing screen before you forget where it was.