1920483 - [a11y] Consider increasing multiple elements from the "Enter confirmation code" custom page

Status: NEW

(Fenix :: Accounts and Sync, defect)

Description

[Adina Petridean QA [:apetridean]]

Attachment: enterConfirmationCode.JPEG

Steps to reproduce

1. Have Google Accessibility Scanner installed.
2. Go to Sync and save your data → Use email instead
3. Enter the username. Scan the "Enter confirmation code" page.

Expected behavior

No suggestions are made.

Actual behavior

Consider increase the size of the following elements:

1. "for your Mozilla account" text: 25dp
2. Enter 6-digit code: 27dp
3. the website URL: https://accounts.firefox.com/.....: 23dp
4. the "firefox.com": 17dp

Device information

• Firefox version: Firefox 131.0b9
• Android device model: Xiaomi Pad5 (Android 13)

Comment 1

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

Items included:

1. This text should not be detected as interactive
   • @Jeff, do you know why it could be marked up as a control by automatic tools like the Scanner?
   • Assuming, there is no action associated with it - If there is an event listener attached to it or/and it's coded as a button or such, this would need to be removed because it'll be misleading for assistive technology users and would create a high access-S3 issue
   • If this text is, in fact, actionable - its visual styling would need to be adjusted to visually communicate it for users without assistive technology too, and this would again be a high access-S3 issue.
2. [Main size concern] Usually, the size of 27pd would be triaged as access-S2. That's being said, the 6-digit code input field's height is an access-S3 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, while the ability to activate and fill in the input is crucial for the entire flow.
3. These two lines (items 3 and 4) need to be combined in one container that is a link - so it would be just one tab/swipe stop for assistive technology, to reduce duplication and avoid confusion, since both the URL and the title should be pointing to the same target. This would allow for a larger touch target to be created.

Possible remediation for Item 2:

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

Also, consider making the entire block for the input actionable instead of the label/placeholder text alone.

Comment 2

[vpomerleau]

Thanks for transferring these over to the Accounts team, @Jeff! Points 1-2 are definitely for us, but I believe point 3 might be outside our control and part of Fenix's UI?

@Anna I'm not sure why point 1 is detected as interactive - it's part of the heading element and is not focusable and has no event listener or interactive functionality.