35

I want to detect whether a screen reader is running on a user's machine to avoid sound clashing with audio tag in html. If so, please provide details on how this could be done.

FelipeAls
  • 21,711
  • 8
  • 54
  • 74
shuklendu
  • 475
  • 1
  • 5
  • 8
  • 1
    +1. I don't have any experience of this, but surely a screen reader which supports the ` – Spudley Oct 10 '11 at 11:43
  • It's generally not possible to detect if a screenreader is running. (Even if some accessibility technology is running, it might not be an audio-based screen-reader: it could be a braille-based screenreader, or a command-and-control voice control app that uses some of the same techniques as a screenreader does.) What would you want to do differently if you could determine that a screenreader was running? – BrendanMcK Oct 10 '11 at 12:18

3 Answers3

18

You should probably not try to do anything special even if you could detect that a screenreader is running. Even if you get it right for one group of screenreader users, you may get it wrong for another group. It's best to concentrate on writing good clean HTML5 in the first place.

Note that not all screenreader users use text-to-speech; many use braille output. Additionally, other types of accessibility tools - such as content highlighters and voice input apps - use the same techniques and APIs (eg. DOM, MSAA) that screenreaders do, so any technique that "detects a screenreader" will likely detect these also - so you cannot assume that it means that the user is fully blind and using only speech.

As things currently stand, the audio tag is currently not universally accessible, different browsers have different levels of accessibility support - see HTML5 Accessibility and scroll down to audio for more details of current support. I've seen some pages that add HTML5-based controls plus javascript after the audio tag so they can provide their own UI to ensure that keyboard or screenreader users can play/stop the audio as needed. (Eventually, when browsers catch up, this should not be needed.)

As far as general accessibility goes, WCAG 2.0 (Web Content Accessibility Guidelines) recommends that any audio that plays automatically for more than 3 seconds should have an accessible means to pause or stop the audio. (I'd go even further and recommend against using any automatic audio - when using tabbed browsing, it's often impossible to determine which tab the audio is coming from.)

Ryan B
  • 3,364
  • 21
  • 35
BrendanMcK
  • 14,252
  • 45
  • 54
  • Downvoter - care to explain why the downvote? Is there something that could be improved with this answer? – BrendanMcK Dec 05 '16 at 21:53
  • 2
    I'm not the downvoter, but one example I can think of is if you're writing a framework that provides some fundamental control like a date input with an attached picker. For mobile platforms or for screen readers, you may wish to use input[type=date]. It's hacky but not difficult to detect mobile; screen readers would be covered by the question. – Adam Leggett Oct 24 '18 at 21:54
  • 9
    I'm not the downvoter either - in my case I have a perfectly functioning native select drop down that works as well as can be expected with screen readers. But when I "enhance" it with a plugin like selectric, it is suddenly useless for screen readers. If I knew a screen reader was in play, I'd never init the selectric and everybody would be happier. – changokun Mar 14 '19 at 21:12
  • 1
    I can't downvote, but in my case, I want to have two different tables with lots of data, one for screenreader with normal tags and and stuff and another
    table for making it nice in the responsive view. As Garrett Dimon said: "Data tables don’t do so well with responsive design. Just sayin’."
     – Kurt Lagerbier May 18 '21 at 17:34
4

While likely not a fully reliable way, a screen reader's progress can be detected via javascript using the focus event, as the user skim through content.

A hidden "skip navigation link" (http://webaim.org/techniques/skipnav/) should it be focused, would be one way to detect whether someone is using a screenreader.

Even though it doesn't address the audio part of the question. I just wanted to provide this partial solution, as I was looking for possible ways to detect screen-readers myself.

hexalys
  • 5,177
  • 3
  • 31
  • 56
  • 3
    What about folks who navigate with the keyboard who _aren't_ using a screenreader? – steveax Apr 18 '13 at 08:49
  • @stevax, To my knowledge, beside the described usual IE quirks, navigating with the keyboard implies a focus event whether you use a screenreader or not. Safari's assisted VoiceOver for example, does apply focus while skimming though content using the keyboard. And a tabindex can be used to force focus on a specific element by order, when the user tab through the page. – hexalys Apr 19 '13 at 00:11
  • Maybe I wasn't clear in my comment. The point I was trying to make is that it would not be possible to distinguish between screen reader users and folks who for some other reason (possibly a11y related) navigate with the keyboard who aren't employing a screen reader and that trying to target screen reader users this way would probably lead to a big bag of hurt. – steveax Apr 19 '13 at 02:29
  • I see what you mean. "display:none;" being invisible to screenreader is also a hurdle. However, one conceivable way to do it, would be to tag a middle element as aria-hidden="true" or aria-disabled="true" within 3 consecutive ones. If element 1 and 3 receive focus that would indicate assistive technology being used (for having skipped one), other than a simple keyboard navigation. As I don't foresee any keyboard navigation tools or plugin applying any WAI-ARIA related states or properties. – hexalys Apr 19 '13 at 06:32
  • Some example code (probably outdated) that detects the differences in javascript events (between a screen reader, keyboard user, and mouse user) is here http://dylanb.github.io/screenreaderdetection/ – robocat Sep 01 '16 at 00:02
  • @robocat - just tried that for Chrome, and it said "Browser platform not supported" – clayRay Mar 02 '23 at 02:30
1

You cannot detect screen readers using javascript, you cannot detect screen readers using any client side technology. You can detect software that is running an MSAA client using Flash. More details about how it works and why it is not useful and should not be used to detect screen readers is available here: Developer Beware: Using Flash to Detect Screen Readers

Steve Faulkner
  • 2,572
  • 15
  • 17