Accessibility findings that travel cleanly to dev
Capture the failing element, dictate the WCAG criterion, publish a markdown review your developer (and their coding agent) can fix from.
This page is for a11y specialists, frontend leads, and engineers running an accessibility pass before launch. The pattern fits anywhere on the use cases for visual product feedback hub, but accessibility findings have a particular shape, visual context plus a precise standards reference plus a specific element, that the markdown export carries well.
The problem
An accessibility pass produces findings in four incompatible formats. Axe gives you a list of violation codes and CSS selectors. Lighthouse drops a JSON report. The manual portion of the audit lives as annotated screenshots, captioned in whatever tool the auditor uses. The summary lands as a 12-row spreadsheet, one issue per row, with a "screenshot" column linking to a Drive folder.
None of those formats survive the handoff. The developer who has to fix the contrast issue on the secondary button needs the visual context, the source URL, the standard being violated, and the expected behavior. The spreadsheet has three of those. The axe report has two. The screenshots folder has one. By the time the dev (or the dev's coding agent) has the full picture, half the audit has been re-explained in Slack.
The CobaltCapture workflow
Open the page under audit. In another tab, hit Capture screen at cobaltcapture.com and pick the window. Drag a box around the failing element, the low-contrast button, the unlabeled icon, the focus trap, the form field with no associated label. Hit Dictate and walk through the finding as you'd explain it in a remediation call: "Color contrast 3.2:1 between the white button text and the light blue background. Fails WCAG 1.4.3, contrast minimum. Should be 4.5:1 minimum for normal text. The fix is to darken the button background to at least #1B6BBA or use the existing cobalt-700 token."
Move on. Capture the next issue, the <div> masquerading as a button, the modal that doesn't trap focus, the image with alt="" that's carrying meaning. Each capture stamps the source URL on the finding automatically. Hit Publish. You get a single review URL covering the whole pass.
What the output looks like
The published review is a structured markdown document. One H1 for the audit, one section per finding with an embedded screenshot, the source URL, and your dictated rationale with the WCAG reference inline:
# Accessibility review, checkout flow
Source: https://staging.example.com/checkout
Color contrast on the Submit button is 3.2:1 between white text and
the light-blue background. Fails WCAG 1.4.3 (Contrast Minimum, Level
AA), which requires 4.5:1 for normal text. Darken the background to
cobalt-700 (#1B6BBA) or use the existing primary-button token, which
already passes.
The close icon in the coupon modal has no accessible name. Screen
readers announce it as "button" with no further context. Fails WCAG
4.1.2 (Name, Role, Value). Add aria-label="Close coupon dialog" or a
visually hidden text label inside the button.
The promo-code input has placeholder text but no associated <label>.
Fails WCAG 1.3.1 (Info and Relationships) and 3.3.2 (Labels or
Instructions). Add a <label for="promo"> above the input; the
placeholder can stay as supplementary hint text.
Why this beats axe + spreadsheet
Axe and Lighthouse are good at the half of accessibility that machines can detect. They find missing alt attributes, low contrast ratios, and ARIA misuse. They are bad at carrying that finding into a state a developer can act on. The output is a violation code (color-contrast), a CSS selector (.btn-primary > span:nth-child(2)), and a link to the rule documentation. The dev opens the link, reads the spec, hunts for the element in DevTools, and reconstructs the visual context the auditor already had.
CobaltCapture keeps the visual context attached. The cropped screenshot shows the exact element the auditor saw failing, the source URL points to the page in the build under test, the dictated rationale carries the WCAG reference and the suggested fix in plain language. The markdown export drops straight into a Linear ticket, a GitHub issue, or a Slack DM, and the same .md file can be fed to Claude Code as feedback.md in the repo. The dev (or the agent) reads the visual, reads the standard, applies the fix, moves to the next item. No second translation step.
The other thing the markdown carries that the spreadsheet doesn't: the auditor's voice. Dictated findings tend to include the suggested fix, the existing token to use, the related issue elsewhere on the page. Typed spreadsheet cells tend to read "fails 1.4.3" and stop there. The dev gets a verdict, not a remediation path.
Who this is for
Accessibility specialists running formal audits against WCAG 2.1 or 2.2. Frontend leads doing a pre-launch a11y pass on a feature branch before it ships. Compliance teams whose audit findings have to be both auditor-readable and developer-actionable. Anyone whose accessibility report currently lives in a spreadsheet and gets re-explained in Slack every time the dev asks "which button on which page?"
Capture your first review.
About a minute from open tab to a shareable URL your agent can ingest.
Start capturing