Owl Listener Accessibility Tradeoff Analysis
Analyse accessibility tradeoffs rigorously — because "we can't do everything" is often true, and the quality of the tradeoff decision determines who gets included and who gets excluded.
When Tradeoffs Happen
Conflicting User Needs
- Autoplay captions help deaf users but moving text distracts users with ADHD
- Simplified language helps cognitive accessibility but may feel patronising to some users
- High contrast helps low vision but can cause eye strain for some migraine conditions
Accessibility vs Other Requirements
- Performance: rich accessibility features vs page load speed
- Deadline: full accessibility vs shipping on time
- Complexity: accessible custom component vs simpler but less accessible native element
- Cost: comprehensive testing vs budget constraints
Partial Implementation
- You can make 80% of the feature accessible now and 20% later
- Which 80% do you choose and who does the 20% exclude?
Analysis Framework
For each tradeoff, work through:
1. Who Benefits from Option A?
- Which user groups gain accessibility
- How many users are affected (estimated)
- How severe is the barrier if Option A is not chosen
2. Who Benefits from Option B?
- Same analysis for the alternative
3. Who Is Harmed by Each Option?
- Which user groups lose accessibility or experience degradation
- How severe is the harm
- Is the harm permanent or temporary (will it be fixed later?)
4. What's the Severity Asymmetry?
- A user who CANNOT complete a task (blocked) is more severely affected than a user who finds a task HARDER (friction)
- Prioritise removing blockers over reducing friction
- Prioritise permanent disabilities over situational impairments (situational users have other options; permanent users may not)
5. What's the Reversibility?
- Can this decision be changed later without significant cost?
- If yes: choose the faster option and plan the improvement
- If no: choose the more inclusive option and accept the delay
6. What's the Precedent?
- Does this decision set a pattern for future features?
- A shortcut taken once becomes a standard if not documented
- If it sets a bad precedent, the long-term cost exceeds the short-term saving
Tradeoff Documentation
Every tradeoff must be recorded using the decision-documentation format with these additional fields:
Who is excluded by this decision: Name the specific user groups affected.
Severity of exclusion: Blocked (cannot complete task) vs friction (harder but possible).
Remediation plan: When and how will the excluded users be served. "Screen reader support for the chart component is deferred to sprint 14. Workaround: data table below the chart provides the same information. Tracked in JIRA-4521."
Review date: When will this tradeoff be reassessed.
Red Lines
Some tradeoffs should never be made:
- Never ship a feature that is completely inaccessible by keyboard
- Never remove existing accessibility to meet a deadline
- Never deprioritise accessibility fixes that block task completion
- Never treat "we'll fix it later" as acceptable without a tracked ticket and a deadline
Assessment Questions
- Have both sides of the tradeoff been analysed for who benefits and who is harmed?
- Is severity asymmetry considered (blocked vs friction)?
- Is there a documented remediation plan for excluded users?
- Has a review date been set?
- Does this decision set a precedent that needs to be managed?