1836576 - [a11y] New Tab in the Private Window has inaccessible Search field

Status: RESOLVED DUPLICATE of bug 1865210

(Firefox :: New Tab Page, defect, P3)

Description

[Anna Yeddi [:ayeddi]]

Attachment: Inaccessible search input - Private window.png

STR

1. Keyboard:
   1.1. On macOS, ensure Use keyboard navigation to move focus between controls checkbox under OS Settings > Keyboard > Shortcuts is checked
   1.2. Open Firefox - New Window or New Private Window
   1.3. Using Tab key navigate to and focus the search input field on the New Tab page
2. Screen Reader:
   2.1. Ensure a screen reader is running
   2.2. Open Firefox - New Private Window
   2.3. While on a New Private Window, use Tab key to navigate to the main content area and to focus its search input field on the New Tab page

Expected

1. Keyboard:
   1.1. When a bookmarks bar is focused, pressing Tab key would move the keyboard focus to the search input on the main content area
   1.2. the focus outline on the search input would be visible and a user would be able to enter their search request using keyboard only
2. Screen Reader:
   2.1. When a bookmarks bar is focused, pressing Tab key would move the screen reader focus to the search input on the main content area
   2.2. a screen reader would announce an informative accessible name of the search input and its role (i.e. Search with Google or enter address, text field) and a user would be able to enter their search request using keyboard only

Actual

1. Keyboard:
   1.1. When a bookmarks bar is focused, pressing Tab key moves the keyboard focus to the promo section or discovery stream, skipping the search input on the main content area altogether
   1.2. user would not be able to enter their search request in a main content area using keyboard only while mouse/touch users would have this affordance
   1.3. Sighted users among the keyboard users would see focus jumping over the input field that would not follow the expected/visual reading and focus orders
2. Screen Reader:
   2.1. When a bookmarks bar is focused, pressing Tab key moves the screen reader focus to the promo area's heading, skipping the search input on the main content area altogether.
   2.2. Using browsing mode of a screen reader does not provide access to any content above the promo section, i.e. with VoiceOver VO+Left Arrow (Ctrl+Opt+Left Arrow by default) keys do not move the focus and user hears a beep marking that they're at the very beginning of the content - while the Firefox logo and search input are both visually present on the screen
   2.3. Results of 1.2 and 1.3 above would apply for a screen reader case as well

On the Private Window's New Tab, the button and its nested input that are creating the search component are both provided with tabindex=-1 that removes both controls from a keyboard focus order and aria-hidden=true removing it from the Accessibility tree for any assistive technology. On the default New Tab the button has only the tabindex=-1 property exposing it to an assistive technology while keeping it inaccessible with a keyboard alone.

Firefox 113.0.2 (64-bit), 114.0 (64-bit), beta are tested on macOS, but per the markup of the page, the same results would be on all devices and platforms

Comment 1

[Anna Yeddi [:ayeddi]]

Attachment: Inaccessible search input - New Tab, button is not focusable.png

Comment 2

[Anna Yeddi [:ayeddi]]

Per the discussion with Jamie, dropping this to s3 (albeit a high one) given that there is a workaround (you can search from the address bar) and given that we don't really have a clear path forward here with the existent UI which aims to bring all searches to the address bar, since we want that to be the primary search surface.

Comment 3

[Anna Yeddi [:ayeddi]]

Closing this bug as a duplicate of a bug 1865210 which includes the further conversation and a green light from the Accessibility PM to discuss it during the New Tab revamp work as well