# Developer-ready findings: the fields that get a finding fixed and retested in one pass

*A free template from Tabstop Studio. Use any of it, change anything, no sign-up. The CSV is `developer-ready-findings-template.csv`. Its two example rows are fictional: delete them before you use it.*

This is the format we quote from fastest. Your report probably has most of these fields already. The ones that save the most time are usually **component**, **state**, **steps**, **tested_with** and **retest_check**. With those, a developer can find the code, reproduce the failure and know what "fixed" means, all without a call.

The columns match the ones in our guide [Writing accessibility findings developers can fix](/guides/writing-accessibility-findings-developers-can-fix). They also import directly into common triage sheets.

| Column | What goes in it | Why a developer needs it |
|---|---|---|
| `id` | Your finding ID, never renumbered | The change log and the retest refer to it |
| `status` | Fail (or Pass / N/A for items kept for the record) | Passing rows are skipped on import |
| `title` | One sentence: what fails | The headline of the change-log row |
| `page_or_template` | A URL, a pattern such as `/products/*`, or `sitewide` | Many findings are one template fix that clears every page using it |
| `state` | The page state the bug lives in, e.g. "after Add to cart (drawer open)" | Many of the worst failures only exist after an interaction |
| `component` | The part of the page, e.g. "Cart drawer", "Header menu" | Maps the finding to a theme section or snippet: the fastest route to the code |
| `instances` | How many places, e.g. "every product with size options" | Shows it's one fix, not forty |
| `element` | A CSS selector or element, if you have one | Removes guesswork on busy pages |
| `wcag_sc` | Success criterion number(s), e.g. `2.4.3` | The pass criterion for the retest |
| `wcag_version` | 2.1 or 2.2 | Which standard the retest uses |
| `level` | A / AA | Which items are in an AA scope |
| `severity` | Your scale (Critical / High / Medium / Low) | Order of work, and "critical and high first" first jobs |
| `impact` | Who is blocked and how | Stops "fixes" that pass a scanner but not a person |
| `steps` | Numbered steps from page load | A developer sees the failure in two minutes |
| `actual` | What happens now | Confirms everyone is looking at the same failure |
| `expected` | What should happen, in user terms | Defines "fixed" |
| `retest_check` | How you'll check it: keys, screen reader commands, tool and rule | The developer runs the same check before handoff, so the first retest passes more often |
| `tested_with` | OS, browser, assistive technology and versions | A fair retest uses the same setup |
| `detected_by` | automated / manual / both | Shows which findings a scanner will confirm and which need a person |
| `rule_id` | The axe or other tool rule, if automated | Lets the fixer re-run the same rule |
| `third_party` | App or plugin name, if the markup comes from one | App findings take a different route (settings, swap or vendor ticket) |
| `recommended_fix` | Your suggested approach (optional) | A starting point; a different fix is fine if it meets the SC |
| `evidence` | Screenshot or video file name | Shows the failure without a meeting |

## Three habits that make fixes cheaper for your clients

1. **One finding per root cause, with every place it occurs.** "Product card images have no alt (all collection pages)" is one fix. Thirty rows for thirty pages look like thirty fixes and get quoted that way.
2. **Say where you think it lives, if you know.** Name the theme, the app (reviews, pop-up, chat) or content entered in the admin. App and content items take a different route, and saying so up front keeps quotes honest.
3. **Write the retest check before anyone fixes anything.** It becomes the pass criterion. When the fixer and the auditor agree on it first, there's no argument at retest.

## About Tabstop Studio

We find and fix accessibility issues in Shopify and WordPress theme code, on staging, with a before/after report mapped to every issue ID. When an auditor's audit is the starting point, we fix and the auditor retests. We don't sell overlays. Questions, or a client audit you'd like quoted: everest@tabstopstudio.com.