accessibility · local-first tool
Track a Form Fix Until Someone Rechecks the Actual Control
A ticket can be closed when code changes, even though the instruction, label, or error message still fails for a keyboard or screen-reader user.
Record a field label, observed issue, source page, fix owner, release version, retest method, and human confirmation; separate code completion from verified user-facing behavior.
What changes the result: the field, observed behavior, release identifier, and assistive-tech test you actually performed.
Privacy: Calculations run in this browser tab. This tool has no input-upload, account, or AI endpoint. The site may send a page-view signal to Cloudflare; this tool does not add form entries to that signal. A draft is stored only if you choose “Save draft on this device”; that browser storage is not encrypted. Avoid identifiers or sensitive details, and delete saved drafts when finished.
Your entries
The starting rows below are fictional examples. Edit them, replace them with non-sensitive labels and values, or load the sample again. The result is not advice or a source verification.
Amount fields use the same units you enter; the app does not choose a currency. Dates are the ones you provide. Up to 100 rows per run.
Calculated output
What the calculation does
Count the source-status labels the user selected and keep each claim beside its date, source, and limitation. The tool does not read or verify linked sources, and a 'supports' label is not independent fact-checking.
Question to keep open: Should a fix be closed when code is merged or only after the control is retested in the interface?
Boundary: This log is not a conformance audit or legal certification. Test the deployed form with keyboard, assistive technology, and people who use it; W3C's form guidance is a starting point, not proof of compliance.
Copy includes the headline, aggregate metrics, and boundary—not the row-by-row input. The CSV contains entries you choose to download. Review it before sharing.