Accessibility and Inclusive Content
Accessibility Issue Remediation Log
Assign, resolve, verify, and document content accessibility defects, affected users, reproduction conditions, standards, ownership, and regression coverage.
Free editable Markdown · Accessibility leads, content operations teams, and product teams ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Issue record
- Issue ID and title
- [Stable identifier]
- User task
- [What the person needs to do]
- Affected users
- [Access method or need, not diagnosis assumption]
- Page/component/state
- [Exact location]
- Environment
- [Browser, device, AT, zoom, locale, build]
- Steps to reproduce
- [Ordered steps]
- Expected behavior
- [Accessible outcome]
- Actual behavior
- [Observed barrier]
- User impact
- [Blocked, confusion, loss, effort, risk]
- Requirement/reference
- [If reviewed]
- Severity and rationale
- [Model used]
Remediation and verification
- Root cause
- [Content, design, code, data, process]
- Affected scope
- [Components, pages, locales]
- Acceptance criteria
- [Observable outcomes]
- Content owner
- [Name/team]
- Technical owner
- [Name/team]
- Temporary mitigation
- [If any]
- Fix version/build
- [Identifier]
- Verification environment/result
- [Exact]
- Regression prevention
- [Test, guidance, component rule]
Closure checks
- Reproduction evidence avoids sensitive data.
- User impact is described independently of tool severity.
- Shared patterns and locales were searched.
- Acceptance criteria include important states.
- Original task is retested after remediation.
- Automated and manual checks are combined appropriately.
- Temporary mitigation is not mistaken for closure.
- Verification owner and residual risk are documented.
How to use this template
- Reproduce the issue and record task, environment, state, expected behavior, actual behavior, and user impact.
- Identify affected pattern, pages, components, locales, and relevant requirement.
- Set severity, owners, acceptance criteria, and a source-level remediation plan.
- Implement and test original plus boundary and regression states.
- Record verification, residual risk, prevention, release, and closure approval.
Describe the barrier from the user's task
Record page, component, state, content, input, device, browser, assistive technology, zoom, and steps. State the expected accessible behavior and what actually happens. Explain which users may be affected and how: blocked completion, lost context, hidden information, increased effort, or risk of an incorrect action. Attach minimal evidence that avoids personal data. Map a relevant requirement when qualified to do so, but keep user impact central.
Fix the source, not one occurrence
Identify whether the defect belongs to content, design, component implementation, data, configuration, or authoring guidance. Search for other uses of the same component or pattern. Define acceptance criteria before remediation, including states such as empty, error, loading, translated, mobile, and zoomed. Avoid a patch that satisfies an automated rule while leaving the task confusing. Assign content and technical owners when both wording and implementation contribute.
Verify and prevent recurrence
Retest the original steps with the relevant tools and, where possible, a person experienced with the affected access method. Record build, environment, result, evidence, tester, and residual limitation. Add appropriate automated checks, component tests, editorial guidance, or design-system documentation. Reopen an issue when the fix introduces a new barrier or does not hold across affected contexts. Track temporary mitigations separately from complete remediation.
See the fields in context
Fictional example: unlabeled map filter
Route Fern is an invented site and all findings are illustrative.
- Barrier: A fictional icon-only filter button is announced only as “button” in the named test environment.
- Impact: Screen-reader users cannot predict that it opens route type filters.
- Scope: The same shared icon button appears on four invented map pages.
- Fix: Add the component's programmatic name “Filter routes,” expose expanded state, and retain visible focus.
- Verification: Retest all four pages, open/close behavior, focus return, translated labels, and automated component coverage.
Frequently asked questions
Should every automated alert become an issue?
Review it first. Automated tools identify useful candidates but can produce false positives and cannot fully assess user impact.
Who assigns severity?
Use your documented model with accessibility expertise and product context. Consider task blockage, affected scope, frequency, and consequence.
What counts as verification?
Reproduce the original task in the relevant environment after the fix and test important variants. A merged pull request alone is not verification.
When can a mitigation close an issue?
Only when it fully meets acceptance criteria. Otherwise track mitigation, remaining barrier, responsible owner, and completion date.