Create Temporary (Stopgaps)
Stopgaps are temporary, partial measures introduced by builders when full accessibility is not yet feasible.
Stopgaps occupy a crucial and sometimes debated space within the accessibility lifecycle because they arise when foundational work has been delayed or neglected.
They are positioned in the builder-side care space based on two key factors: 1) who implements them (the builders) and 2) the intent of the action (reduce harm while better solutions are implemented).
They are not polished or equivalent alternatives to accessibility -- they are acknowledged as incomplete. Yet they demonstrate care by reducing harm in the short term. Stopgaps do not and should not replace the obligation to fully remediate. They buy time, reduce harm, and signal accountability.
Stopgaps are designed to be replaced by more complete acts of care. They must have end-dates. If a stopgap is intended to serve as a long-term fix, then it is a manifestation of neglect.
Unlike support channels, which can operate as standing infrastructure, stopgaps are defined by their temporary status and explicit path to replacement. A stopgap can be a temporary interface, alternate workflow, manual service, or human-mediated route, but it must be openly partial and scheduled to disappear once fuller access exists.
Role in the ENABLE Model
In the ENABLE model, stopgaps are builder-side interventions that arise late in the process -- often during iteration or as a last-minute response to accessibility issues. While not perfect, they represent care in motion: a refusal to launch without any accommodation.
Why stopgaps matter
Failing to do anything until a complete solution is ready places all of the burden on end-users in the mean time. Stopgaps shift some of the burden away from navigator-side by creating something usable now -- however flawed -- with a clear path toward long-term remediation. They admit imperfection while centering immediacy and dignity.
Examples
FTC Order Requires accessiBe to Pay $1 Million for Deceptive Claims (January 3, 2025)
-- Federal Trade Commission
- The FTC ordered accessiBe to pay $1 million for falsely claiming its AI overlay widget could make "any website compliant" with WCAG. The order bars the company from making such claims for 20 years. According to UsableNet, 25% of all digital accessibility lawsuits in 2024 targeted websites using overlays -- cited as barriers, not solutions. This enforcement action confirms that overlays are not stopgaps when marketed as permanent fixes; they are manifestations of neglect and disability dongles.
CVS MinuteClinic Kiosk Settlement via Structured Negotiation (May 16, 2024)
-- Law Office of Lainey Feingold
- After the National Federation of the Blind sued over inaccessible check-in kiosks at CVS MinuteClinics, CVS agreed to remove the kiosks over 18 months and ensure any replacement technology works for blind people. This settlement demonstrates what a legitimate stopgap pathway looks like: acknowledging the barrier, providing interim alternatives, and committing to full remediation -- not deploying an overlay and claiming the problem is solved.
- A plain-text syllabus shared alongside an inaccessible LMS until proper remediation is complete
- A manually updated HTML list of video links and transcripts while an inaccessible video library is rebuilt
- A temporary toggle to disable a broken interactive chart while a screen reader-friendly redesign is in progress
- Publishing alt-text as a separate document when it's not yet integrated into the CMS
- Marking inaccessible parts of a site with “skip this section” notes and an accessible summary link
Are overlays stopgaps?
Maybe, but only under certain conditions, which are rarely met.
To qualify as a stopgap, an overlay must:
- Be deployed by builders, not users (this is true for builder-side overlays, but not navigator-side tools)
- Be reactive, addressing a known, current harm or accessibility failure
- Be acknowledged as temporary, with a plan for full remediation
- Not obscure or delay true accessibility work (unlike Disability Dongles)
In reality, most overlay implementations fail this test. They're often:
- Used proactively as a crutch in place of true accessibility
- Marketed as complete solutions, not temporary ones
- Known to introduce new problems for assistive tech users
Therefore:
In theory, a builder-side overlay could be a stopgap if it's deployed in response to a specific harm, with transparency, and a plan for removal or replacement.
In practice, overlays are deployed as accessibility solutions -- so they're not considered stopgaps in the ENABLE model. They're more often manifestations of neglect or performative care, which is not care.
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.”
“It's not WCAG-compliant, so we've allocated additional resources to ensure you can get the information in the meantime.”
“We didn't want to delay access entirely, so we've posted this stopgap with the current limitations clearly stated.”
Neglect sounds like
“Accessibility is coming later. Users will just have to wait.”
“No one should be using that part of the system yet anyway.”
“We're focused on the main experience -- the edge cases will have to wait.”
Real-world Scenario
An airline launches a new booking system with a flashy design -- but screen reader users report that the calendar widget is inaccessible. Instead of forcing them to call support or abandon their purchase, the dev team pushes out a basic text-based booking form within days. It doesn't have all the bells and whistles, but it works. The team labels it “temporary access form,” collects feedback, and commits to full remediation. This stopgap keeps users in the loop, and out of harm's way, without pretending the problem is solved.