[a11y] `firefox/all` page isn't accessible for screen reader user flow

[reemhamz]

Description

The page allows users to go through a series of selections for the page to determine the correct Firefox browser to download. However, when a user selects an item, the page reloads and doesn't automatically take a screen reader user to the next selection, forcing them to go through the page from the beginning. It also doesn't make it obvious to screen reader users that they've selected somethig until they've reached the selection after tabbing through again after reload.

The page used to be form-based, which is far more accessible, but due to performance challenges, the page has been updated to this new layout. (https://github.com/mozilla/bedrock/issues/9845)

We need a way to make the page less jarring and easily navigable for screen reader users.

Steps to reproduce

1. Open screen reader application
2. Open https://www.mozilla.org/en-US/firefox/all/
3. With the screen reader, tab through and select an option

Expected result

• Screen reader user can continue on to next section to select next option without disruption

Actual result

• Page reloads and disrupts the flow of the screen reader user, forcing them to start from the beginning of the page

Environment

MacOS, Voice Over utility

[reemhamz]

Dropping this here as a good resource: https://www.w3.org/WAI/tutorials/forms/multi-page/

[robhudson]

I could imagine it's possible to progressively enhance that page, so that a click doesn't do a full reload, but still fetches content from the backend and displays it as the next step. But a fresh page load anywhere in the steps (from clicking a shared link, e.g.) will server-side render it and send it to the browser. There's ways we can differentiate between the two on the backend to send a subset of HTML vs a full HTML page. Just one idea.

[Ingi-Hong]

I have interest in taking this on. Would combining #15293 with Javascript's .focus be reasonable approach? In the same function that the innerHtml is set the appropriate html element could be found through ID or classname and focused.

edit, I tested this out and realized .focus forces a scroll to the element. There's a preventScroll option but it's not widely supported on android browsers.

[janbrasna]

Scrolling (into view at least) should generally be fine, however I was not successful in getting the AT pick up the changes that way; I had to start tinkering with live regions and assertive announcements, but it looked like it might need overhauling the markup as some of the changes happen outside of what I was able to mark up in the live regions (and e.g. logo changes would happen earlier in the DOM order than the heading text change etc. making constraining the changes within live regions somewhat tricky…) so you may need to experiment a bit.