Skip to main content

Create (Stopgaps)

Stopgaps are temporary, partial measures introduced by builders when full accessibility is not yet feasible. They are not polished or equivalent alternatives -- they are acknowledged as incomplete. Yet they demonstrate care by reducing harm in the short term. Stopgaps do not replace the obligation to fully remediate; they buy time, reduce harm, and signal accountability.

Role in the ENABLE Model​

In the ENABLE model, stopgaps are pre-launch 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 the burden on end-users. Stopgaps avoid this by creating something usable now -- however flawed -- with a clear path toward long-term remediation. They admit imperfection while centering immediacy and dignity.

Examples​

  • 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
Overlays?

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 pre-launch overlays)
  • 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

In reality, most overlays 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 pre-launch 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 rarely meet this bar -- so they're not considered stopgaps in the ENABLE model. They're more often manifestations of neglect, 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, but it should let you 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.