How can various stakeholders use the ENABLE Model to foster a more equitable and accessible world?

The ENABLE Model serves as a comprehensive field guide for understanding accessibility failures and, more importantly, for fostering a more equitable and accessible world by mapping the gap between intended care and the burden placed on disabled individuals. It is designed for a wide range of "stakeholders" including builders, caretakers, activists, educators, researchers, leaders, and anyone who believes accessibility is a necessary form of care.

To use the ENABLE Model effectively, stakeholders can approach any broken experience by answering four key questions:

1. Where could access have been delivered earlier? This focuses on Pre-launch Interventions.
2. Who's carrying the burden now -- and how? This highlights Post-launch Compensations.
3. What caused or sustained the problem? This explores the Forces that Disable and Forces that Enable.
4. What have people actually done in response -- to prevent harm or survive it? This involves examining Manifestations.

The model emphasizes that accessibility has two halves: Pre-launch Interventions, which are acts of care preventing inaccessibility before a product or service is released, and Post-launch Compensations, which are the acts of survival people are burdened with when accessibility is an afterthought. When care fails upstream with the builders, the burden grows and lands downstream on the end-users. By understanding both sides, stakeholders can take action.

Here's how various stakeholders can use the ENABLE Model:

1. Builders, Designers, and Developers

This group is central to the Pre-launch Interventions phase, where fixes are smaller, cheaper, and kinder. Their role is to proactively embed accessibility.

• Set Requirements that Include Accessibility: Designers, developers, and project leads should mandate inclusion from the outset, defining accessibility as a core obligation rather than an add-on. This prevents exclusion from being "baked into infrastructure". Care sounds like: "Our speech recognition AI must be usable by people who stutter". Neglect sounds like: "Accessibility is not a deliverable" or "It's not in the spec". Examples include incorporating WCAG 2.2 compliance into design contracts or making accessibility part of the "definition of done" for all features.
• Create Accessible Content: Content creators must ensure words, images, media, documents, and data are perceivable, understood, and interactive for people with disabilities in accessible formats. Care sounds like: "Our slide deck must include alt text for all images" or "Let's produce a transcript and a plain language summary alongside this podcast". Neglect sounds like: "The visuals are self-explanatory, no need to describe them".
• Design Accessible Experiences: Designers should intentionally create user interfaces and interactions that are equitably usable, considering a range of impairments and ensuring compatibility with assistive technologies. Care sounds like: "We've built keyboard navigation into every interactive element". Neglect sounds like: "We only designed for the average user".
• Develop Accessible Implementations: Developers must build technology that supports inclusive use, choosing appropriate tools, frameworks, markup, and logic to ensure functional accessibility. Care sounds like: "All interactive elements must be reachable and operable by keyboard". Neglect sounds like: "It works with a mouse -- good enough".
• Test for Accessibility: QA teams and developers must evaluate digital products to ensure people with disabilities can perceive, operate, understand, and interact with them, ideally involving disabled users in manual and automated testing. Care sounds like: "We included blind and motor-impaired testers in our usability test". Neglect sounds like: "We didn't have time for a full accessibility audit".
• Triage and Prioritize Accessibility Issues: Teams must assess the severity, impact, and urgency of discovered accessibility issues, treating them as essential, top-priority blockers. Care sounds like: "Accessibility failures are not tech debt -- they're production bugs". Neglect sounds like: "Only one user reported that issue, so it's not a priority".
• Iterate to Address Shortcomings: This involves making continuous improvements based on testing and feedback, ensuring that accessibility is a recurring obligation, not a one-time task. Care sounds like: "We got feedback from a blind user who couldn't complete the checkout process -- we're deploying a fix in the next sprint". Neglect sounds like: "We already launched; we can't prioritize that kind of fix at this point".
• Create Stopgaps: When full accessibility isn't immediately feasible, builders can introduce temporary, partial measures to reduce harm in the short term, with a clear plan for long-term remediation. Care sounds like: "We know this is a partial solution -- here's what we can offer right now while we work on a real fix". Neglect sounds like: "Accessibility is coming later. Users will just have to wait".

2. Leaders, Policymakers, and Decision-Makers

This group sets the strategic direction and allocates resources, crucially influencing Requirements Setting, Triage and Prioritization, and Iteration.

• They can implement institutional policies like Section 508 or ADA standards, ensuring accessibility is non-negotiable in procurement and project definitions.
• They must ensure accessibility issues are not deprioritized or dismissed, understanding that such neglect delays remediation and communicates to disabled users that their needs are non-essential.
• They can prevent abandonment, which occurs when accessibility that once existed is withdrawn, by budgeting for long-term accessibility and preventing regressions.

3. Educators and Content Creators

These stakeholders shape future norms and ensure foundational materials are accessible.

• Integrate accessibility into curricula: Educators can use the ENABLE Model to teach students about inclusive design, accessible content creation, and the societal cost of neglect. For example, medical schools can update curricula with first-person disability perspectives.
• Produce inherently accessible materials: Similar to builders, educators and content creators should ensure their content includes alt text, captions, transcripts, and plain language summaries from the start.

4. Activists, Advocates, and Researchers

These groups play a vital role in identifying, documenting, and pushing for change when accessibility breaks down.

• Recognize and document Post-launch Compensations: Activists and researchers can use the model to identify how users are burdened with Assistive Technologies, Third-party Tools, System Settings changes, User Workarounds, Human Help, Feedback & Bug Reports, Legal Action, Protest & Public Pressure, or being forced to Switch to Alternatives. Each compensation signals a systemic failure upstream.
• Assert Rights and Stage Protests: When other avenues fail, advocates and users can formally demand accessibility through legal complaints (e.g., ADA, Section 508) or public pressure campaigns. This forces institutions to confront neglect.
• Use Media, Storytelling, and Advocacy: This is a powerful force that shapes behavior across all ENABLE stages. Stakeholders can publish first-person accounts, document unaddressed gaps, expose hidden labor through videos, elevate community demands, and embed disabled voices in planning. This isn't just "raising awareness," but strategically influencing how care is prioritized.
• Understand Forces that Disable: Researchers and advocates can analyze structural, cultural, and organizational choices that lead to failures, such as Abandonment (when accessibility is withdrawn) or Disability Dongles (flashy, useless tools designed without disabled people).

5. Users and Teammates

Even without formal roles in development or policy, individuals can contribute by recognizing and reporting issues, and by understanding their own compensatory actions.

• Spotting workarounds: Users can recognize when they are creating workarounds or relying on assistive technologies, prompting them to look into the Post-launch Compensations section.
• Providing Feedback: Users can submit bug reports and feedback, holding creators accountable for accessibility issues. While this is a burden, it can also be a catalyst for improvement.

In essence, the ENABLE Model provides a vocabulary for care and neglect, a map of roles, a structure that includes tech, policy, education, and more, and a compass for anyone who wants to build a more equitable world. It shifts the focus from disability as a personal problem to inaccessibility as a systemic failure, encouraging proactive solutions over reactive burdens.

Utilizing the ENABLE Model is like being a cartographer for a complex city: you don't just map the inaccessible roads (post-launch compensations) but also identify where the bridges could have been built (pre-launch interventions), recognize the forces that allowed roads to crumble, and share stories of those navigating the terrain, all to ultimately help redesign the city to be traversable for everyone.

---

💡 Dive into the ENABLE model now →