1503876 - Modal dialogs on the New Tab Page allow keyboard to focus visually grayed out controls behind the dialog

Status: NEW

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

Description

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Attachment: add top site form not reachable with keyboard only navigation.gif

[Affected versions]:
- Nightly v65.0a1, Build ID 20181030224027
- Beta 64
- Release 63

[Affected Platforms]:
- All Windows
- All Mac
- All Linux

[Steps to reproduce]:
1. Open the browser with a clean new profile and open a new tab.
2. Click the "..." Top Site section button.
3. Press "Tab" once and then "Enter".
4. Press "Tab" again and observe the behavior.

[Expected results]:
- The first field is focused.

[Actual results]:
- A different element underneath is focused.

[Notes]:
- The "Cancel" and "Save" buttons are also unreachable with keyboard only navigation.
- The issue is also reproducible with the "Add Search Engine" pop up and the "Cancel" and "Add" buttons are unreachable with keyboard only navigation.
- Attached a screen recording of the issue.

Comment 1

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Attachment: add search engine not reachable with keyboard only navigation.gif

Adding an additional screen recording.

Comment 2

[Anna Yeddi [:ayeddi]]

Attachment: Focus-leaves-Edit-Shortcut-modal.png

The issue is still present in today's Firefox 120 Nightly: the keyboard focus is still leaving the modal dialog Edit shortcut on the New Tab Page that is not an expected behavior for modal dialog pattern.

Another issue with the dialog is the lack of an accessible name for the dialog container.

It looks like (per the gifs attached) that the original behavior was similar, just the focus would not even land on the dialog at first and the focus was likely passing through the background controls instead.

Comment 3

[Anna Yeddi [:ayeddi]]

Attachment: Focus-order-of-the-Edit-Shortcut-dialog-is-not-restricted.png

The focus of the keyboard should be restricted to the modal dialog until this dialog is dismissed. Then the focus should return to the triggering element. In this case, to the ... control for the shortcut that was used to open the dialog.

Comment 4

[Anna Yeddi [:ayeddi]]

Attachment: Focus-is-not-restricted-for-the-Settings-dialog.png

The same issue applies to the Settings modal dialog on the New Tab.

These issues would cause a keyboard users to loose the keyboard focus (because it is barely seen when the rest of the page is grayed out) and not know what the position of their keyboard focus is, in fact. Also, it may cause users to activate some control by a mistake and spend time returning back to the previous page and location within the page, which would affect more users with limited mobility and users of alternative input devices such as switch controls etc.

Comment 5

[Maxx Crawford [:maxx]]

Steps to solve modals with this issue:

1. Convert modal to use HNT reusable Modal component
2. Implement the same focus trap method that was implemented on TopicSelection.jsx.

Comment 7

[Anna Yeddi [:ayeddi]]

Attachment: Accessibility Inspector of Firefox showing Tabbing order for the New Tab page where the Settings dialog is covering visually the rest of the page but does not limit the focus behavior

The same issue applies to the Personalize New Tab / Settings dialog