In my last email, I suggested keeping a record of the reasoning behind an accessibility decision.
The record should separate the decision from its rationale, explain where it applies and name the circumstances that would make the team reconsider. Writing something down shouldn't make it set in stone. Circumstances change and decisions should change with them. But the records should remain. I'd also want to know which alternatives were considered and where the evidence was limited.
I could care less about the meeting transcript or the history of who disagreed with whom. This won't help anyone judge the decision later.
Some of you wrote back and asked about a starting point, a template. So here's what I use. I try to keep each section short and use it for decisions worth sharing, not every adjustment to a screen. I want someone to finish reading these and have enough understanding to judge if this applies to them or their situation is different and why.
- Decision title. Name the chosen approach in plain language so someone scanning a list can recognise it.
- Record metadata. Include a stable identifier, status, creation date, last updated date and the responsible team or contact. Make it clear whether the decision is proposed, accepted or deprecated.
- Context. Describe the user task, the barrier or question and the constraints that shaped the decision. Include only background needed to understand the choice.
- Applicability. Explain where this decision applies and where it does not. Name relevant boundaries so another team can judge whether to reuse it.
- Decision. State what the team chose. Be specific enough to guide design, implementation and testing without turning this into a complete technical specification.
- Rationale and trade-offs. Explain why the team chose this approach, what it enables and what compromises it accepts. Connect the reasoning to the user task.
- Options considered. Briefly describe credible alternatives and why you didn't go with them.
- Evidence and uncertainty. Summarise relevant research or testing and link to supporting material. Distinguish observed results from assumptions, noting what remains untested or unresolved.
- Related work. Link to the component, design, implementation or other decision records someone may need. If this replaces an earlier decision, link to that record and mark the relationship.
- Review triggers. Describe what new evidence or changed circumstances should prompt reconsideration. Include a review date if the decision is temporary.
It's not terribly complicated and most of these things you're going to be discussing in your meetings anyway. Take notes and fill this in afterwards.
You'll save yourselves and the people coming after you loads of headaches and double work.