I recently built a browser extension like Vimium that lets you browse the web with just your keyboard shortcuts. While building it, I came to realize that it has great potential for helping the disabled. I searched more on the topic of web accessibility and learned about screen readers.

I tried out several screen readers including Voice Over, Chrome Vox, and NVDA. The experience wasn't very good, but that might be because I'm unfamiliar with them. They seemed dumb, tedious, repetitive, and simply not tailored to the web.

It prompted me to question whether there is a better way to make the web accessible to the visually impaired. I don't know much about the screen readers and why they work the way they do, but I felt that at the very least they can be more intelligent and configurable. As a person without disabilities, I'd be tempted to enhance my browsing experience with a screen reader regularly if it provided the right features and didn't interfere with regular browsing.

I did some more research, and it seems that desktop screen readers like NVDA are limited by the accessibility APIs provided by browsers. They provide the features they can given the limited view of a web page a browser provides.

I think it's possible to make a much more user-friendly screen reader-like application as a browser extension which has direct access to the underlying document and browser APIs. My experience building a keybinding extension has shown that there is a lot of information in web pages that could be exploited to make browsing better that is simply ignored. It baffles me that Google's Chrome Vox screen reader extension does little beyond emulating the functionality of existing desktop screen readers.

Before I invest significant effort trying to create a screen reader alternative, I'd like to know if I'm missing something. Are my thoughts misguided? What bothers you about screen readers? How can they be improved?

  • There are many different accessibility issues affecting web users. Visual impairment is just one of them. Your plugin also solves problems experienced by people who don't have a steady hand to operate a mouse. Screen readers will always be limited by the amount of extra content that developers add to help them. Semantic markup, meta data, microdata, and microformatting all help but only if they are present. Without these, it becomes an exercise in AI to interpret meaning and inference in content and convey this to the user in a meaningful way. Jul 4, 2017 at 8:10

2 Answers 2


I work on many accessibility projects for Screen-Reader(SR) users. We've been developing for JAWS screen-reader, NVDA, Voiceover and lately we used our own screen reader for a specific app.

Common SRs are far from perfect, and all screen-readers have a platform/browser of predilection. They all handle a given website differently

SR share the same basic features: Speed of voice, reads the HTML according to the aria-attributes, provide lists for all types of components (links, buttons, headers, lists, tables...) and provide a way to navigate in these standard components. They all have a bunch of shortcuts to quickly access components of a certain type.

For sure there is a lot to improve in the navigation ! Especially in the search feature.

I believe there is a huge room of growth for SR because none of them gives proper satisfaction (voiceover being the most advanced).

A website which is not designed for screen-reader users will likely fail an accessibility audit.

I warn you though, if you want a screen reader to be used,it has to be on the OS because a visually impaired user won't want (or even be able) to switch their screen reader every time they open and close their browser

  • Do you really think OS integration is that important? At the very least, NVDA has an API for external applications. In theory, you could detect the presence of a desktop screen reader and design a web extension screen reader that smoothly integrates with the desktop screen reader. It would only take over browser interactions and let the desktop screen reader handle the rest. This would allow faster development, and more room to experiment with new features. Do it well enough, and it would free desktop screen readers from having to handle the many corner cases of the web.
    – Eejdoowad
    May 4, 2017 at 14:48
  • @Eejdoowad A screen reader needs OS integration in order to work with desktop applications (including the desktop itself); at the very least it needs to support the OS's accessibility API. BTW, there is also a web-based screen reader called WebAnywhere, but it obviously only supports web content.
    – Tsundoku
    May 9, 2017 at 17:02
  • The WebAnywhere project is really interesting. Thanks for sharing. They have many useful resources. My understanding is the OS accessibility APIs are provided by browsers to describe what is being viewed. I can use them to power a screen reader application.
    – Eejdoowad
    May 10, 2017 at 2:56

I don't know much about screen-readers as well, but I am building websites and have also been busy with learning how to make websites better readable for screen-readers.

ScreenReaders are so "dumb" because they usually don't know a lot about the website they are on. If the webmaster uses a list for the navigation header, the screen-reader will have to guess. I could imagine those screen-readers are analyzing the position of that list to find out if it could be for navigation.

They know few things because HTML isn't really semantic. With HTML5 it got better, but only a fraction of a fraction of todays website are using it properly.

Also so-called WAI-ARIA Landmarks exist to make HTML even more semantic. Those are attributes that can be attached to a HTML Tag to make it more semantic. Screenreaders can then understand what they see. However, this is also used very sparse yet and quite something to learn in order to use it's full capabilities.

That means, screen-readers aren't dumb, the content actually is just unsemantic, so screen-readers can't easily find out what information they read and how to interpret it.

It will still be a long process even until most important websites will semantise their content.

  • My understanding is that screen readers on web pages using semantic elements and aria roles because browsers don't expose much else. They don't actually see web pages directly. Browsers provided a limited API and a simpler tree with less information that mirrors the DOM. You mentioned using positioning to determine e.g. where a navigation is. That's exactly the sort of technique I think can be used to make screen readers better. Would it be possible to create a screen reader that completely ignores semantic information and does its own analysis?
    – Eejdoowad
    May 5, 2017 at 14:20
  • @Eejdoowad I think it would be possible. But it would be lots of work. If the browser only provides an API, I could even think of the screen-reader making it's own request to the website, of course with all cookies sent with. But that sounds really complex and slow. May 5, 2017 at 16:22
  • So, if the screen reader is an extension built into the browser, accessing the information is easy. The hard part is analyzing and doing something useful with it. Extensions also have access to the automation API, which is what is exposed to traditional screen readers. I think I'll start by writing a web extension screen reader with the standard feature set like Chrome Vox, then innovate on that base.
    – Eejdoowad
    May 5, 2017 at 22:06
  • @Eejdoowad That is a really nice project. I wish you good luck! May 6, 2017 at 9:58
  • 1
    @Eejdoowad You should be aware that screen readers already contain lots of shortcuts, e.g. for calling up a list of all the links on a page, all the headings on a page, etc. Please make a careful analysis of what screen readers are already capable of, or you will risk reinventing somebody else's wheel.
    – Tsundoku
    May 9, 2017 at 17:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.