Bug: New Tab Wallpaper options provide confusing markup and navigation pattern
Status: RESOLVED
Priority: P3
Resolution: FIXED
Created: 2024-10-07 13:54:43+00:00
Resolved: 2025-03-05 11:20:17+00:00

### Prerequisites: 
1. Ensure a screen reader is running, i.e. an NVDA on WinOS, OR use keyboard alone

### STR: 
1. Open Firefox on the New Tab page
2. Navigate to the "Personalize New Tab" (gear icon) button and activate it
3. On the "Personalize New Tab" dialog, locate and navigate to either of wallpaper group options, i.e. `Photographs`, and observe the screen reader announcement
4. Press arrow keys on the keyboard and observe the focus behavior

### Expected:
1. The first option within a wallpaper group options would be focused with `Tab` key, but then the focus would move between options with arrow keys. Pressing `Tab` key again would move the focus to the next section, away from the wallpaper options.
2. The options announced as radio buttons or buttons that would imply an option could be selected/checked/pressed and that could be one and only one option (i.e. `{Solid colors}, radio button`) - this would also help screen reader users to predict the keyboard navigation pattern and to use shortcuts to access these controls as well.

### Actual:
1. Each wallpaper option is separately focusable with `Tab`, arrow keys do nothing, unless there is already a text being entered - then it functions in forms mode as any text input would do (not an expected behavior).
2. The options are marked up as input fields with autocomplete and, for instance, the NVDA announces each option as `{Solid colors}, edit, has autocomplete, {selected}`:
    1. Marking this as `access-S2` issue, because this markup is risking to block users of keyboards and any assistive technology from being able to access wallpaper selection. This is not an expected type of control for the functionality provided, the announcement is unnecessarily verbose and confusing, and it forces users to Tab through the entire list even when they are trying to bypass this section, this may prevent users of switch, voice controls, and other assistive technology to successfully operate with the control, and it also allows the keyboard text input that is visible on-screen (refer to the screenshot in the comment #1). Neurodiverse users who rely on screen readers to better understand and follow the content would be especially severely affected by this confusing announcement and behavior.

### Remediation:
1. Mark up wallpaper options as radio buttons ([native HTML - inputs with type=radio](https://html.spec.whatwg.org/multipage/input.html#radio-button-state-(type=radio)) or [ARIA ones](https://www.w3.org/WAI/ARIA/apg/patterns/radio/)) and ensure their `name` attributes are the same so one radio group is created for Accessibility API.
2. Alternatively, each option could be a `<button>` with `aria-pressed` set to `false` by default and to `true` for selected option, and these buttons are wrapped in a group/fieldset. The keyboard navigation is still expected to use [arrow/list style navigation](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#keyboardnavigationinsidecomponents) for efficiency of keyboard users.

### Note: 
1. The same keyboard pattern applies to both the parent options (i.e. `Photographs`) and their inner options (i.e. `City landscape`) - the inner options are marked up as radio buttons, but their HTML `name` values are unique, thus one group is not created by them and each one is `1 of 1` group.