[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.