Accessibility failure: Actions with no feedback to screen reader users

[NicktheGeek]

🐛 Current behavior

Screen reader users do not get any feedback at all when actions happen.

For example, in the pagination element, Click one of the page buttons and things happen on the screen but there is no indication that anything happened and if they press tab it just takes them to the next focusable element after the pagination link they just clicked.

Imagine how this experience works for someone with no vision. They have navigated the list, find a pagination list, and decide to go to the next page. Only when they click it, as far as they are aware, nothing happens. It feels very broken if this is your experience. It's actually a major accessibility failure.

I have been able to make some improvements by making text that is updated when search or filters are used into an aria-live container, but the page navigation doesn't update anything in a way that will work for this.

🔍 Steps to reproduce

1. Go to one of the demos like this eCommerce demo
2. Activate a screen reader and use the keyboard to navigate to the pagination
3. The link will be announced like "link: page 2." Different screen readers announce the link differently but it will be like that
4. Press enter to trigger the link
5. The screen updates with new items but no announcement is made.
6. Press tab and it will move focus to the next item so screen reader users may have no idea anything changed.

Live reproduction

https://codesandbox.io/p/sandbox/github/algolia/instantsearch/tree/templates/instantsearch.js

💭 Expected behavior

The ideal solution here would be to use a container with aria-live="polite" aria-atomic="true" attributes and update the page text like <div class="screen-reader-only" aria-live="polite" aria-atomic="true">Page ${page number} loaded</div>

Package version

instasearch.js 4.78.1

Operating system

No response

Browser

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Haroenv]

Thanks! These changes sound reasonable, but practically it's not easy to make changes to the DOM with our current setup. Have you considered using a connector? seems like for #6618, #6619 as well those are all about pagination widget so likely could all be solved with a single custom widget.

If you'd be interested in contributing, it could be an option to convert the pagination widget to one that uses the same rendering along all flavours in the next branch, and then fix these issues. Let me know if you have bandwidth for that