Understanding the Usages, Lifecycle, and Opportunities of Screen Readers' Plugins
Farhani Momotaz, Md Ehtesham-Ul-Haque, Syed Masum Billah · 2023 · ACM Transactions on Accessible Computing · doi:10.1145/3582697
Summary
This study investigates why blind users rely on screen reader plugins and how these plugins are developed, distributed, and maintained. The researchers combined two methodological approaches: semi-structured interviews with 14 blind participants (ages 24-52, expert to beginner screen reader users) and analysis of approximately 2,000 online posts from NVDA user forums and GitHub issues. The research identifies four primary reasons blind users turn to plugins: to make inaccessible or partially accessible applications usable, to modify existing screen reader features for better usability, to receive audio feedback on keystrokes and commands, and to add useful shortcuts. The study analyzed 160 NVDA plugins (76 third-party, 84 built-in) and organized them into 13 functional categories including enhancing usability, patching application-specific inaccessibility, enhancing text accessibility, multiplexing audio synthesizers, masking input-output devices, and making graphics accessible via computer vision. A key contribution is the "tripartite collaboration" model showing how plugins emerge from complex interactions among three stakeholder groups: individual blind users who identify needs, online communities of blind users who discuss and fund solutions, and developer communities who create the actual plugins. The typical development cycle takes 3-4 months from initial request to deployed plugin. The study reveals significant tensions between user communities and developers, with nearly half of user-reported issues being declined for various reasons including reproducibility problems, obsolete platforms, or technical difficulty.
Key findings
Only a handful of developers create screen reader plugins, and they are well-known within the blind community by first name. Plugin development requires both programming skills and deep knowledge of screen reader APIs—a combination few possess. Development tools and IDEs are themselves often inaccessible to blind users, creating a barrier for those who want to write their own plugins. The plugin ecosystem suffers from serious structural problems. There is no central repository for plugins across screen readers (only NVDA maintains one), forcing users to find plugins through ad-hoc Google searches, personal websites, and Telegram groups. This creates security vulnerabilities—participants reported downloading malware disguised as plugins, with one losing 350GB of data to ransomware. Once installed, users rarely uninstall plugins even when unnecessary, and most plugins receive no maintenance after initial release, becoming obsolete as screen readers and operating systems update. Financial incentives are notably absent. Developers create plugins voluntarily, and while community members sometimes crowdfund $5-100 for specific plugins, this is not sustainable. Screen reader vendors like Freedom Scientific declined user requests for custom plugins. The lack of economic model contributes to the ecosystem's slow growth and poor maintenance. The study found 96.8% of high-priority (p1) GitHub issues get resolved compared to only 40.4% of low-priority (p4) issues, and 90.1% of issues tagged as "bugs" are fixed. Users strategically frame their requests as bugs to increase attention.
Relevance
This research has immediate practical implications for screen reader vendors, accessibility practitioners, and researchers. The finding that plugins effectively extend assistive technology capabilities suggests that plugin-based distribution could be a viable model for deploying accessibility research prototypes—researchers could reach blind users quickly without requiring changes to commercial screen readers. For organizations, the study highlights the informal, fragile nature of screen reader customization. When employees rely on plugins for productivity software accessibility, they may be using unmaintained code from unknown sources with potential security risks. IT departments supporting blind employees should be aware of plugin dependencies and their maintenance status. The recommendations include creating a unified, community-driven plugin repository hosted on peer-to-peer infrastructure with ratings, version control, and security information. The authors also propose developing automated tools that could help non-programmers generate plugins by describing desired behaviors. For accessibility researchers, the tripartite collaboration model offers a framework for understanding how accessibility solutions emerge from community needs and how to engage with these communities effectively.
Tags: screen readers · NVDA · JAWS · plugins · extensions · assistive technology · blind users · online communities · qualitative research