Found a workaround for the web client reading issue

6 сообщений, 1 страниц:  1 ↖ Вернуться к списку тем

счёт: +0

1. Nikola,

Hello. I've managed to get a solution for live regions. It appears that speech priority normal and low don't work. When setting all messages to either high or critical, you do get auto reading.

счёт: +0

2. Aminiel,

IN which browser and OS ahve you observed this ?

счёт: +0

3. StormProductions,

@Aminiel, this happens in Chrome on Windows. I can confirm.

счёт: +0

4. Nikola,

Exactly. Happens in firefox too, at least with NVDA. What are the differences even supposed to be with all the speech modes? On the client, we can just interrupt the previous messages or no so not sure about the difference.

счёт: +0

5. Aminiel,

Normal priority, as the name says, is the default one.
Technically speaking, messages at this priority are put in a zone with aria-live=polite.
It normally means that it is read when the browser is on foreground, as soon as possible, but without interrupting previous messages.

Messages at high priority are put in a zone with aria-live=assertive.
It normally means that an incoming message is read immediately as soon as it arrives, interrupting any other message currently speaking.

The critical priority exists because some browsers/screen reader combinations don't follow the standard. They threat aria-live=assertive the same as aria-live=polite, unless the zone is also role=alert.
I made it different than the high priority because additionally, some screen readers prefix each message by words like "Alert!" or even play a sound when role=alert.
As high priority messages which need to be interrupting are still quite common, for example those which ask a question or tell that it's your turn, it would probably be annoying to have "Alert!" repeated all the time.
IN this mode we are also almost totally sure that the message is spoken even if the browser isn't in focus. For high priority it depends on the browser and screen reader.

Finally, the low priority is exactly like the normal, except that message won't be spoken and not be added in the queue of messages at all in certain specific cases.
Currently, this behaves like the normal one as there are no such specific case at the moment. IN the future, I'm sure that it will be extremely useful; though probably not before 2nd or even 3rd quarter of 2018.

The biggest problem with aria-live regions is that browsers and screen readers don't behave all the same all the time.

My results so far are the following:

  • Safari+VO is probably the combination the most following standards defined by W3C/WAI ARIA, both on Mac and iOS (tested with IOS 10, my phone doesn't support iOS 11)
  • Jaws in any browser doesn't take aria-live=assertive into account, unless role=alert. I didn't tested yet with Jaws 2018.
  • Chrome with any screen reader doesn't take aria-live=assertive into account too
  • Everything works fine with firefox, both on windows with Jaws or NVDA and on linux with Orca, except as noted above about aria-live=assertive with Jaws
  • I don't remember by heart what works and what doesn't work with IE11, but IE is quite capricious
  • IE10 and lower are no longer officially supported
  • I don't have any android phone or tablet, so am unable to test
  • Edge is still so ... bizarre ... that I'm almost certain nbody use it anyway

With the hope that everything is clarified

счёт: +0

Последнее изменение Aminiel, 19.11.2017 07:10:53

6. Nikola,

Thanks Aminiel for the great explanation, all is clear now and makes sense. For chrome, you could fil a bug on crbug.com for standards chrome isn't following if you have a google account , and we can all upvote it so hopefully they can get it sorted.

счёт: +0

6 сообщений, 1 страниц:  1 ↖ Вернуться к списку тем

Ответить на тему

Чтобы писать на форуме, вам нужно сначала войти.

Забыли пароль? Создать учётную запись