Most accessibility widgets include a screen reader mode. In many cases, activating the screen reader mode will enable a completely different screen reader built into the widget. These alternative screen readers are not at all practical. To start, they are incredibly primitive. I and most other full-time screen reader users rely on advanced screen readers with many configurations that can be tailored to the person’s specific needs and preferences.
Widgets try to replicate what assistive technologies like JAWS or NVDA already do, but they fall flat. Operating on a simplistic level, they lack the sophistication to interpret dynamic website interactions and the flexibility to address real-world usability needs. Worse, they force us to abandon tools we’ve spent years mastering, turning accessibility into a roadblock rather than a solution.
The proprietary screen readers built into accessibility widgets have no configurable settings. Furthermore, they tend to operate very differently from traditional screen readers. So, if I were to try to use an accessibility widget effectively, I would have to learn an entirely new screen reader on the fly and be able to apply my knowledge to an unfamiliar site to get anything done. It quickly became apparent that this simply was not going to work.
Accessibility widgets want me to turn off my native screen reader
It always makes me laugh when the widget prompts me to disable my own screen reader in favor of the built-in version. Something about the idea of having to enable and disable other computer programs in order to get one site to work correctly seems to go against the very pillars of accessibility and usability. To say the least, it is far from intuitive and seamless. If I choose not to shut off my native screen reader, the two readers will compete for stage time and essentially talk over each other to the point where I am overwhelmed by a meaningless word soup. This is clearly not going to work either.
Even when I reluctantly follow the widget’s instructions to disable my screen reader, I often find myself stranded if their screen reader decides to stop working. It’s like handing someone a parachute with holes in it—no thanks.
Other accessibility widgets that do not have a built-in screen reader are really no more useful. Activating the accessibility mode changes some aspects of the page, but contrary to what one may think, it actually makes the page less accessible overall. I find that the page will usually become less responsive and a general lag will develop between when I press a key and when I get verbal feedback from the screen reader.
This lag isn’t just frustrating—it’s disruptive. Widgets throw in random clutter, like unlabeled buttons or meaningless labels. I’ve had perfectly functional elements suddenly transform into gibberish, like a shopping cart button morphing into something like, “This may be Cart, The Cart, or Product List.” Honestly, I’d rather deal with the original site.
More recently, I have found that these screen reader modes prompt a strange button label issue with sudden uncertainty about what the button is. For example, I was recently on a retail site trying out the accessibility widget.
Before activating the widget, the cart button was labeled “Shopping Cart.” After enabling the widget, the cart button was announced as “This May Be Cart, The Cart, The Shopping Cart, or Product List.”
This label is utterly bizarre and is unlike anything I have ever heard. Using the so-called screen reader mode, there was sudden random uncertainty about button labels that were not there before. You cannot make this stuff up. In almost every case, the screen reader mode in accessibility widgets is worse than the default version of the website. Instead of improving usability, these tools disrupt functionality, adding confusion and frustration.
To make matters worse, relying on widgets introduces significant legal risks. Despite their marketing claims, widgets are no substitute for real accessibility.
According to the W3C, “No tool alone can determine if a site meets accessibility guidelines. Knowledgeable human evaluation is required.”
Recent lawsuit data confirms this, with over 20% of accessibility lawsuits in early 2024 involving websites that used widgets. Businesses hoping to take a shortcut with these tools often face higher risks.
I have found that most sites make it very easy to enable the accessibility widget. However, often widgets are difficult to disable. The only thing I can do is reload the site and hope that the widget defaults to the off position.
Let’s be clear—this isn’t accessibility. A genuinely accessible experience gives users control, not locks them into tools that make things more complicated.
If the only thing you need to do to make a site work for you is change the text size or background color, these widgets may serve you well. However, for those who require advanced functionality out of an accessibility solution, widgets miss the mark by a long shot.
Real accessibility doesn’t come from a widget. It comes from websites designed and tested with people with disabilities in mind. This means involving experts, using real assistive technologies, and tailoring solutions to meet actual needs. That’s how you make a site usable for everyone.
Check your website's accessibility with our free accessibility testing tool.
Editors note: This is a post written by our frequent Marketing Contributor, Michael Taylor. This post reflects his opinions and experiences. Read more about Michael and some other posts on his experience online here.