Fable

Product teams hire disabled testers on Fable to run usability sessions before shipping new features.

What it is

Fable is an accessibility research and usability testing platform where product teams work directly with people with disabilities to test digital products before launch. Teams use Fable to recruit assistive technology users, run moderated and unmoderated usability sessions, and gather feedback on prototypes, live sites, and apps. Fable’s testers use a range of assistive technologies and provide insights on real-world accessibility and usability barriers. This is a builder-side intervention at the qa-testing stage, shifting responsibility for access upstream.

Why it matters

When product teams do not include disabled people in usability testing, accessibility issues are often missed until after launch, forcing disabled users to compensate or file complaints. Fable enables teams to catch and fix accessibility barriers before products ship, reducing downstream burden and preventing harm. This represents a builder-side intervention that redistributes labor from disabled users (who would otherwise have to report or workaround barriers) to builders who proactively address access.

Real-world example

• REI used Fable to collect feedback from assistive technology users, improving the usability of e-commerce workflows and saving product teams time and resources (REI Case Study).
• John Lewis & Partners incorporated Fable into their design process to improve their online checkout experience (John Lewis Case Study).
• Shopify’s Themes Team used Fable to prioritize accessibility earlier in the product life cycle, reducing usability bugs (Shopify Case Study).
• Typeform worked with Fable testers to understand real-world usability for people with disabilities, going beyond automated accessibility checks (Typeform Case Study).

What care sounds like (builder-side interventions)

Care at the QA testing stage involves including disabled people in usability research:

• "We schedule usability sessions with Fable testers before every major release."
• "We review Fable feedback alongside automated test results to prioritize accessibility bugs."
• "We budget for ongoing accessibility testing with real users, not just compliance audits."
• "We ask Fable testers to review new features in staging, so we can fix issues before launch."

What neglect sounds like (builder-side interventions)

Neglect involves skipping or minimizing real-world accessibility testing:

• "We rely on automated tools; we don’t have time to test with real users."
• "We’ll fix accessibility if someone complains after launch."
• "We assume our product is accessible because it passes an audit."
• "We don’t know any disabled testers, so we skip usability sessions with them."

What compensation sounds like (navigator-side compensations)

Compensation describes the labor disabled people undertake when upstream QA testing is absent:

• "I had to file a support ticket because the checkout form didn’t work with my screen reader."
• "I use browser extensions to fix inaccessible buttons on sites that never tested with real users."
• "I rely on friends to help me complete tasks on sites that didn’t include disabled testers in their QA."
• "I avoid certain apps because I know they never test with people like me."

---

All observations occur within the context of digital product development, accessibility research, and usability testing for technology teams.

ENABLE Model location

• Builder-side Interventions → Test for Accessibility