Accessibility Decision Documentation

Record accessibility decisions so that future teams understand not
just what was decided, but why — preventing the cycle where good
decisions get reversed because nobody remembers the reasoning.

Why This Matters

Accessibility barriers accumulate quietly through redesigns, framework
updates, staff turnover, and rushed deadlines. The most common cause
isn't malice or ignorance — it's a new team member changing something
without knowing why it was built that way.

Documentation is the immune system. It protects good decisions from
being undone by people who weren't in the room.

Decision Record Format

For each significant accessibility decision, record:

Title

A clear, searchable name.
"Form validation: inline errors instead of summary banner"

Date and Author

When was this decided and by whom.

Context

What situation prompted this decision? What were the constraints?
"During user testing, 3 out of 5 participants with cognitive
disabilities missed the error summary banner at the top of the page.
They corrected individual fields but didn't scroll up to see the
banner, so they didn't know the form hadn't submitted."

Decision

What was decided, specifically.
"All form validation errors will appear inline directly below
the field that needs correction. The error summary banner is
removed. Errors are announced to screen readers via
aria-describedby on each field."

Alternatives Considered

What other options were evaluated and why they were rejected.
"We considered keeping the summary banner alongside inline errors,
but testing showed it created confusion — users didn't know which
error indication to follow."

Accessibility Impact

Who benefits from this decision and how.
"Benefits users with cognitive disabilities (don't need to
remember which fields had errors), screen reader users (errors
announced in context), and all users (faster error correction)."

Risks and Tradeoffs

What might go wrong or what was sacrificed.
"If a form has many errors, the user sees them one at a time as
they move through fields, rather than all at once. For long forms,
this could mean more scrolling. We accept this tradeoff because
contextual errors have higher fix rates in testing."

Evidence

What research, testing, or standards support this decision.
"User testing session 2024-03-15 (5 participants, 3 with cognitive
disabilities). WCAG 2.2 SC 3.3.1 (Error Identification)."

When to Document

Document a decision when:

• You chose between two or more accessibility approaches
• You made a tradeoff that reduces accessibility in one area
  to improve it in another
• You decided NOT to fix something (and why)
• You implemented something differently from WCAG techniques
  for a good reason
• A design pattern was chosen specifically for accessibility reasons
• User testing revealed an accessibility insight that changed direction

Where to Store

• In the codebase alongside the code (preferred — travels with
  the implementation)
• In a shared decision log (wiki, Notion, Confluence)
• In design system documentation (for system-level decisions)
• Never only in someone's head or in a Slack thread

Assessment Questions

1. Are accessibility decisions documented with reasoning?
2. Can a new team member find out why something was built a
   specific way?
3. Are tradeoffs explicitly recorded?
4. Is documentation stored where it won't be lost?