accessibility: Entire message history seems to be visible, causing spurious live region activity

[ndarilek]

Not sure if this is related to #10793. When I use Zulip with my screen reader, the entire message history for a stream is read on first access. This to me suggests that the stream is visible in the DOM, even if it isn't visible visually. As such, we get hundreds or thousands of live regions.

If an ARIA region is actually hidden (I.e. not present in the DOM via display: none or something else) then this shouldn't be an issue. This may be a dupe, but on the off chance that it isn't, I wanted to open it so we could track a fix.

Thanks.

[zulipbot]

Hello @zulip/server-misc members, this issue was labeled with the "area: accessibility" label, so you may want to check it out!

[timabbott]

@ndarilek what's going on here is that we load from the server and render as a large scrollable region up to ~400 messages on first page load. This produces a nice scrolling experience for users interacting with Zulip with a mouse (we actually fetch more from the server, and thus can do rerenders to update the set of messages displayed without going to the server as well). The overall effect is that it's absolutely expected that a large number of messages are in the DOM for a given stream that might be off either the top or bottom of the screen visually. We have plenty of handy JS functions for identifying which messages are visible onscreen.

I suspect handling the ARIA situation for this correctly likely involves making the live ARIA region be e.g. the currently selected message (which has a blue box around it for sighted folks, is integrated with keyboard navigation, and careful tracking logic prevents from going off the top/bottom of the page).

[ndarilek]

No, the live region can't just be the selected message. The current live region strategy is correct--you set it on the area containing the entire message stream. When a new message arrives, I want my screen reader to read that message automatically. If the live region is only the selected message, then changes to *only* that message would present (I.e. if someone edited it.) If a new message arrives, and the only live region is the selected message, then that new message isn't spoken. The problem is that now we're getting 400 live region updates in a short burst. That's not a problem with the general live region approach, it just means we have to refine it further. Are off-screen messages hidden in any way--CSS class, for instance? If so, tweaking that logic to also toggle aria-hidden might work.

[timabbott]

OK. The offscreen messages are just hidden by their scrolling position being off the top of the screen -- so we don't need to run any JS on-scroll.

[timabbott]

One approach we could take is adding the "live region" tag dynamically only when we have the bottom of the screen in view, or something like that?

Another question that comes to mind -- how will this "live region" feature interact with messages being removed and replaced in the DOM (e.g. because of a message edit) -- will it reread those too?