Augment with Third-Party Tools
When websites, apps, or systems are not accessible by default, end-users are often forced to install or activate third-party tools to bridge the gap. These tools may be browser extensions, overlay widgets, plugins, or standalone applications that provide missing accessibility functions like keyboard navigation, text-to-speech, or visual adjustments. These tools are not native to the experience -- they are compensations layered on top.
Role in the ENABLE Model
This compensation arises post-launch, after upstream care has failed. The need to augment with third-party tools is a clear indicator of design and development neglect -- especially when basic interactions or modes of access are not supported natively. In the ENABLE model, this is a burden placed on the user to correct what should have been addressed earlier in the lifecycle.
Why it happens
It happens because accessibility is often deprioritized, delayed, or dismissed during the pre-launch phases of requirement-setting, design, and development. Rather than fixing the root issue, organizations shift the responsibility to users -- especially disabled users -- to find workarounds or patch their experience with external tools. This reflects a systemic neglect of inclusive design and reinforces digital inequity.
Examples
- Using Helperbird, a browser extension that allows users to customize font, contrast, and text-to-speech functionality across inaccessible sites.
- Using the browser extension Vimium to navigate web pages that don't provide native keyboard support.
- Using the MacOS app ShortCat: to control the interface by typing commands, compensating for missing keyboard shortcuts.
- Replacing default interfaces with third-party overlays that offer more accessible interactions
Compensation sounds like
"I had to install a plugin just so I could read the menu."
"None of the buttons worked with my keyboard, so I had to use Vimium."
"I only got through the checkout form because I added an extension that let me zoom the text."
Burden sounds like
"I tried three extensions before one kind of worked."
"My screen reader kept crashing because of the site's overlay."
"I wasted 40 minutes figuring out how to install and configure a tool just to log in."
Real-world Scenario
A blind user tries to access an educational platform to download their course materials. The website uses custom elements without accessible labels, and their screen reader can't interact with them. After repeated failures, the user installs a browser extension that injects ARIA attributes into the page and manually scripts a keyboard shortcut to access the "Download" button. The download finally works -- but the user had to debug, install, and configure third-party tools just to accomplish a task that should have taken seconds. Meanwhile, their sighted peers never encountered any friction.