Search code examples
javascriptaccessibilityalertscreen-readersspeech-synthesis

Web Accessibility. window.speechSynthesis vs role "alert"

To immediately announce error for control/input I have 2 choices:

  1. append HTMLElement to document with role 'alert' and error-message. NVDA reads alert. [errorMessageHere]

const el = document.createElement('div');
el.setAttribute('role', 'alert');
el.className = 'visually-hidden';
el.textContent = 'Some message here';
document.body.append(el);
.visually-hidden {
  position: absolute;
  height: 1px;
  width: 1px;
  top: 0;
  left: 0;
  overflow: hidden;
  clip: rect(1px, 1px, 1px, 1px);
}

  1. Use window.speechSynthesis.speak. NVDA announce [errorMessageHere]

const speakObj = new SpeechSynthesisUtterance('Some message here');
window.speechSynthesis.speak(speakObj)

What I really notice that in NVDA you can disable text-to-speech and show speech-viewer. First case will be logged into speech-viewer but 2nd case - not. NVDA directly announce text when NVDA is opened even if text-to-speech is disabled.

I'd prefer to use window.speechSynthesis.speak instead of creating extra HTMLElements per each case when some details/errors must be announced but I'm not sure is it correct alternative of role 'alert' since window.speechSynthesis.speak is not logged by NVDA at all (but only announced).

Could help me to understand what the best way to be announced/read by screen reader ?

Solution

  • You should definitely prefer live regions and role alert over speech API.

    When using live regions or role alert, the message goes through the screen reader, which brings several important advantages:

    • It is read with the voice settings configured in the screen reader (voice, language, rate, pitch, volume, etc.)
    • It is recorded in speech history, meaning that the user can repeat the message if he/she missed it or didn't understand it the first time. He/she also can copy the message text.
    • The user can interrupt the message before its end (by pressing Ctrl), in case he/she finds it annoying

    None of the three are possible when using speech API:

    • The message is spoken using voice settings that may come from unappropriate defaults, and certainly different from what the user has configured in the screen reader. At best it's quite annoying, at worst the message is totally impossible to understand (the speech can be in the wrong language, way too fast or too slow for example).
    • You can't repeat, copy the text, or shut up the message
    • You may provide UI on your site to configure voice, language, rate, pitch, volume, etc. as well as handle Ctrl key to shut up and something else to repeat, but the user won't take the time to configure this kind of settings and/or learn how to use them on every site visited, so it's mostly useless

    In fact, use cases for each of the two are quite different:

    • Use ARIA live regions, role alert, and other ARIA features of that kind when you need to communicate things specifically to screen readers, like in the present case with error messages.
    • Use speech API when speech is going to be used equally by all users, using a screen reader or not. You can think about a voice assistant or a GPS guide, for example. IN this case you will typically provide ways to configure voice settings as well, because there it perfectly makes sense.