How can I prevent the screen reader from stopping to read the content when the focus is gained to the input field from an aria-live region div?

Question

I have a chatbot interface where a live region div with an aria-live attribute is used to display new messages. The live region updates correctly and the screen reader starts to read the content, but it stops reading in the middle when the focus is gained to the input field. This is causing confusion for screen reader users and makes it difficult for them to understand the new messages.

I am looking for a solution to ensure that the screen reader continues to read the new messages until they are finished and that the focus management is correct when the live region updates. Is there any solution to ensure that the live region updates are announced by the screen reader in a timely manner and the focus is managed correctly?

Screen Reader: NVDA + Firefox

Answer 1

Unfortunately, you can neither ensure that the screen reader will read new messages entirely, neither be certain that new incoming messages won't interrupt older ones. Be it because of a notification of any kind, because the focus changes, or whatever else.

Politeness level of aria-live

Remember by the way that aria-live=assertive normally means always interrupt what's currently being spoken, so it's rarely a good idea to do so. It's much better to keep aria-live=polite .

As my own observations show , you can help a little screen readers to be more stable, avoiding many unwanted interrupts/skips/repeats, though, by being very careful on what you do exactly in the live region.

Change of focus

However and in particular, live-region messages are interrupted when the focus changes. You can't prevent the screen reader from immediately announcing the focused element when the focus changes.

In principle, this is much more important to have this information in a timely manner, rather than any message coming from a live region. Reactiveness to tab, arrow keys and other important keys is crucial for a good user experience, as well as always exactly knowing where you are and what you can/should do.

So, it's perfectly normal that focus change takes the priority almost above everything and that you can't influence on it.

The best way to avoid focus changes taking the priority over everything else is in fact very simple: don't move the focus unexpectedly unless you have a good reason.

In your chatbot example, there is no reason to move the focus upon arrival of a new message. If the focus was in the text box when the user pressed enter to submit a question, the focus should stay there as long as the user don't explicitly leave it by him/herself.

If the focus stays in the text box, then the screen reader user can just have the response automatically read via aria-live, and can directly type in a new message when ready. The conversation can go quick and fluent.

Avoid DOM changes close to focus

Avoid making changes to the DOM enclosing or nearby the text box. A change in the DOM, especially when using frameworks like angular or react, basically means removing it and adding it again. At worst the focus can be completely lost, at best it still creates a focus jump out and in again that will generate an unwanted interruption.

The best is to test what you can or can't change without triggering a DOM rebuild, and adjust your HTML structure in consequence.

Leave users in control to read messages

Don't forget that screen reader user already can quit the textbox and read the missed messages on their own terms. A screen reader already has shortcuts to read backwards (up arrow in NVDA). This will just not work inside the textbox.

Still, it would seem a best practice to allow focussing single chat messages. This is especially true if there are actions you can take on these messages, like replying, editing or deleting.

Microsoft Teams simply allows for tab navigation between chat messages , but it's a dedicated chat application.

If the conversation is embedded in a larger page, it should be treated as a composite widget , which only has one focus stop, but allows focussing the contained controls via vertical arrow keys:

Authors SHOULD ensure that a composite widget exists as a single navigation stop within the larger navigation system of the web page. Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element.

Livechat seems to use arrow keys to navigate between messages