[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)
Tracking
()
| Accessibility Severity | s2 |
People
(Reporter: dpop, Unassigned)
References
Details
(Keywords: access, Whiteboard: [fxdroid][group3])
Attachments
(2 files)
Steps to reproduce
- Enable Talkback.
- Open the latest Nightly 130.0a1 with the toolbar redesign enabled.
- While on the homepage, tap on the buttons from the Navigation toolbar.
- 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.
Updated•1 year ago
|
Comment 1•1 year ago
|
||
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)
Comment 2•1 year ago
|
||
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.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 3•1 year ago
|
||
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.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 4•1 year ago
•
|
||
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.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Description
•