Open Bug 1910656 Opened 1 year ago Updated 1 year ago

[a11y] The homepage items under the navigation toolbar buttons are selected with Talkback instead of the navigation toolbar buttons

Categories

(Firefox for Android :: Homepage, defect, P2)

Firefox 130
All
Android
defect

Tracking

()

Accessibility Severity s2
Tracking Status
firefox128 --- disabled
firefox129 --- disabled
firefox130 --- affected

People

(Reporter: dpop, Unassigned)

References

Details

(Keywords: access, Whiteboard: [fxdroid][group3])

Attachments

(2 files)

Attached video Navbar_Talkback.mp4

Steps to reproduce

  1. Enable Talkback.
  2. Open the latest Nightly 130.0a1 with the toolbar redesign enabled.
  3. While on the homepage, tap on the buttons from the Navigation toolbar.
  4. Observe if tapped buttons are correctly selected and announced with Talkback.

Expected behavior

The buttons on the navigation toolbar are selected and announced with Talkback.

Actual behavior

When tapping the buttons on the navigation toolbar, the homepage elements under the navigation bar are selected and announced with Talkback.

Device information

  • Firefox version: Nightly 130.0a1 from 07/30
  • Android device model: Google Pixel 8 Pro
  • Android OS version: Android 14

Additional information

Not reproducible on a website.

Priority: -- → P2
See Also: → 1913145

This seems to be a high impact access-S3 issue similar to the bug 1908940, because it could also interfere with the Universal Switch scan mode and would make it more difficult to use the interface by sighted TalkBack users (i.e. users with low vision, users with dyslexia, ADHD, etc)

See Also: → 1908940

Oh, after reviewing the other "see also" bugs, it seems to me that this may be the same issue with the view scrolling when assistive technology in use. The scale of the issue would move this high a11y severity S3 across the board to access-S2, thus updating the severity for accessibility too. This may also affect touch users without any assistive technology running, because they may tap a bit off the border of the nav bar and activate an underlying control too.

Accessibility Severity: --- → s2
Assignee: nobody → hoglesby
Status: NEW → ASSIGNED
Assignee: hoglesby → nobody
Status: ASSIGNED → NEW

This is a somewhat old back which stems from the fact that when on homepage the toolbar is placed on top (Z axis) of the home content and can be seen even without the navbar (though with it it's a worse effect).
The issue does not happen when browsing because there the toolbar is shown below (Y axis) GeckoView.
So we could adopt a similar approach for the homescreen which would guarantee no overlapping is possible.

Assignee: nobody → hoglesby
Status: NEW → ASSIGNED
Assignee: hoglesby → nobody
Status: ASSIGNED → NEW
No longer blocks: 1902108
Component: Toolbar → Homepage
Summary: [Toolbar Redesign][a11y] The homepage items under the navigation toolbar buttons are selected with Talkback instead of the navigation toolbar buttons → [a11y] The homepage items under the navigation toolbar buttons are selected with Talkback instead of the navigation toolbar buttons

Piggybacking off Petru’s comment above. https://bugzilla.mozilla.org/show_bug.cgi?id=1910656#c3



This bug affects the current toolbar if placed on the bottom as well as the micro surveys : https://bugzilla.mozilla.org/show_bug.cgi?id=1908940

Essentially, the RecyclerView in the Homepage extends "under" (z-axis) any bottom placed toolbars, surveys or other Fenix-level components that can appear in the Homepage on the bottom.
This is probably done to make the scrolling of the homepage more smooth but in order to fix this problem for all the bottom-placed components, this needs to be fixed at the Homepage level with bounds for the RecyclerView in order to keep it "above" (y-axis) and not "under" (z-axis) the toolbar/other bottom-placed components.

The decision has been made by the toolbar team to move this ticket to the Homepage component as the fix will have to be done on the Homepage rather than with the toolbars.

Whiteboard: [fxdroid][group3]
Assignee: nobody → royang
Assignee: royang → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: