An accessibility finding that a developer cannot locate in the code never gets fixed. It sits in a spreadsheet, gets marked "needs more info," and quietly falls off the list. The problem is rarely the finding itself. It is how the finding was written down. Below are the mistakes that turn a real barrier into an unactionable note, and the correction for each.
Writing "contrast is too low" without the pair of colors
"The text is hard to read" tells a developer nothing they can change. Contrast is a ratio between two specific values, and a developer needs both to fix it. It is tempting to leave it vague because the low contrast feels obvious when you are looking at the screen. It is not obvious in a bug queue three days later.
Fix it by naming the foreground and background and the measured ratio: "Body text #767676 on white measures 4.54:1, but the 12px caption below it uses the same gray at a smaller size and reads as gray mush." If you have the WCAG target in mind, state it: 4.5:1 for normal text, 3:1 for large. A capture of the exact element next to your note removes the guesswork about which text you mean.
Describing an element by how it looks instead of what it is
"The blue button at the top" breaks down the moment there are two blue buttons, or the layout shifts on a narrower screen, or the developer is reading on a laptop where nothing is where you saw it. Visual descriptions are natural to write because that is how you experienced the page. They do not survive the trip to a code editor.
Point at the element instead. In an accessibility review built from screen captures, you can drop a numbered pin on the exact control, so "pin 2" is unambiguous no matter what the developer's screen looks like. Where you know it, add the accessible name or the visible label text: "the Submit button labeled 'Continue to payment'." That gives the developer a string to search for.
Sending a full-page screenshot for a single-element problem
A 1400-pixel-tall screenshot of the whole checkout page, with one note about a missing form label somewhere in the middle, forces the developer to hunt. They scan the image, guess which field you mean, and often guess wrong. The full page feels safer because it shows context, but context you did not ask for is just noise.
Crop the still to the element and the label that should be tied to it. One field, its placeholder, and the text above it is usually enough. If the surrounding structure matters, say so in words rather than shipping the entire viewport. The same principle that makes a cropped still beat an annotated live page applies here: the tighter the frame, the faster the fix.
Reporting a keyboard or screen-reader problem as a picture alone
Focus order, missing focus indicators, and screen-reader announcements are behaviors, not pixels. A screenshot of a form cannot show that Tab skips the third field or that a screen reader reads a button as "button" with no name. Reviewers reach for the screenshot because it is the tool in front of them, then leave the behavior undescribed.
Capture the still for location, then describe the behavior in the comment. Dictation helps here because these findings run long. In Chrome or Edge you can talk through the whole sequence: "Tabbing from the email field jumps past the phone field straight to Submit; the phone field never receives focus." If you would rather narrate a multi-step path, note the same thing that makes dictation beat typing for a long report: you say more when you are not typing. On Firefox you type instead, which still works fine for shorter notes.
Listing findings in the order you noticed them
Ten items scattered by discovery order make the developer sort priority themselves. A missing page landmark and a slightly off-spec placeholder gray land side by side with equal weight. It is tempting to publish in the order you walked the page because that is less work for you. It moves the work downstream.
Group by impact. Blocking barriers first (a form no keyboard user can complete), then the clear violations, then the polish. Each item stays its own captured screenshot so the developer can resolve them one at a time. When you resolve comments without a bug tracker, that per-item structure is what lets two people work the list in parallel.
Handing over a format nobody can pull findings out of
A review pasted into chat, or a folder of loose PNGs with filenames like Screenshot-47, cannot be handed to anyone cleanly. The developer copies notes by hand, the tester loses track of what was fixed, and an AI coding agent gets nothing it can read. Ad hoc formats feel fast in the moment and cost time on every pass after.
Publish the review to one link. Every item, its cropped still, its pins, and its comment live at a short public URL that the developer opens with no login. The same review exports as a PDF or Word doc for a compliance record, and the plain-text markdown at /r/<slug>/markdown is what an agent reads directly. You can also run the whole accessibility pass in one sitting and send it before you close the tab.
Open a new review, capture the first barrier you find, and pin the element you mean. No install, no signup, and free to publish.