1919748 - [Menu Redesign][a11y] Consider increasing the height of the dismissal drag bar

Status: NEW

(Fenix :: Toolbar, defect, P3)

Description

[Vasilica Tamas QA [:vtamas]]

Attachment: MainMenu.JPEG

Preconditions

• Have Google Accessibility Scanner installed.
• Enable Menu Redesign feature from Secret Settings.

Steps to reproduce

1. Navigate to a webpage and tap on 3 dots menu.
2. Scan the Main Menu using the Accessibility Scanner app.
3. Open each submenu: Tools, Save, Extensions.
4. Scan each submenu using the Accessibility Scanner app.

Expected behavior

No suggestions are made.

Actual behavior

• Main Menu: This items height is 16 dp. Consider making the height of this items target 48 dp or larger.
• Submenus: This items height is 34 dp. Consider making the height of this items target 48 dp or larger.

Device information

• Firefox version: Firefox Nightly 132 (2024-09-18)
• Android device model: Samsung GalaxyZ Fold 4, Google Pixel 8
• Android OS version: Android 14

Comment 1

[Vasilica Tamas QA [:vtamas]]

Attachment: SubMenu.JPEG

Comment 2

[Chris Peterson [:cpeterson]]

Aarjav says this bug doesn't need to block the new menu. He will evaluate a11y heights for these drag bar and other UI elements.

Comment 3

[Anna Yeddi [:ayeddi]]

It's expected that interactive target areas are to be 48dp or larger to allow users with limited dexterity and users on the go to better target and tap controls (per WCAG 2.2 Level AAA Success Criteria 2.5.5 and 2.5.8 Target Size (Enhanced and Minimum)). More details could be found in BBC Accessibility guide.

Usually, the height of 34pd would be triaged as access-S3. That's being said, the sheet grabber's height is an access-S4 issue, because the item is an inline control - it's length is larger than 48dp which also enlarges the total area that can be tapped by being long, so marking it as access-S4.

Possible remediation:

The size of the icon is not the main source of the size increase, because having a visually empty but actually tappable (interactive) space around the search icon is included in the size calculation. Also, for the minimum compliance with WCAG 2.2 it would be acceptable to have the touch/interactive target area for the image button to be, let's say, 44 dp but the empty space between this touch area and any other interactive element to be 2 dp on each side (2+44+2 = 48).

Notes:

1. Automatic tools would still likely be flagging it, but it won't be a WCAG 2.2 violation at the moment. But...
2. Font resizing on an OS level does not increase size of image buttons, and larger targets are, in general, easier to use, so going beyond the basic compliance is always encouraged for better user experience across the board

Comment 4

[Aarjav [:aarjav]]

This will be fixed with the Acorn design system bottom sheet component project. This doesn't need to block Menu Redesign.