[ally] The elements from the Customize reader view pop up dialog are not detected by the Android Scanner app
Categories
(Firefox for Android :: General, defect)
Tracking
()
People
(Reporter: apetridean, Unassigned)
Details
(Keywords: access)
Attachments
(2 files)
Steps to reproduce
- Have the Accessibility scanner installed and opened.
- Go to a site with a lot of text content (e.g.wikipedia).
- Enable "Reader view" from the navigation bar.
- Tap the main menu and select "Customize reader view" option.
- Scan the page
Expected behavior
All the elements from the pop dialog are scanned and no suggestions are made.
Actual behavior
The Android Scanner app does not recognise the elements within the pop-up dialog. Instead, the app scans the page behind the dialog, and the accessibility checkers are displayed within the pop-up dialog.
Device information
- Firefox version: Nightly 115.0a1 from 11.05.2023
- Android device model: Huawei Mate 20 Lite
- Android OS version: (Android 10)
Any additional information?
Reporter | ||
Comment 1•2 years ago
|
||
Comment 2•1 year ago
|
||
:Adina, if this issue still can be reproduced, when just a screen reader running, after opening the Customize Reader popup, does the TalkBack focus move to the sheet? If not (that's a bug already, access-S3
), could you still swipe to this popup with logical navigation gestures (one-finger left-to-right swipes)?
Reporter | ||
Comment 3•1 year ago
|
||
Hello Anna! Talkback focus shifts to the sheet when opening the Customize Reader popup, allowing me to swipe using logical navigation gestures.
After navigating through the items within the popup (by swiping from left to right), the elements beneath the popup (starting from the homescreen, search bar, 3-dot menu) are selected, and subsequently, the popup becomes deactivated on the underlying page.
Please see the attached screen recording.
Reporter | ||
Comment 4•1 year ago
|
||
Reporter | ||
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Thank you for the investigation and video, :Adina!
:Eitan, it feels like the URL bar elements (can be heard and TB focus visible starting at 0:35 in the video in #c4) should be hidden since they overlap. Could that be the issue with the overlay view component code or something in how the Accessibility API on Gecko handles the overlays? I know iOS requires the view to be actually cut to avoid VO going under the overlaying content, but I am not sure how we (could) handle it on Android.
Comment 6•1 year ago
|
||
I'm not familiar with the scanner's internals, so it is hard to say. I think it is worth trying to properly hide the toolbar and seeing what the scanner gets. Either way that needs to be done for proper talkback support. In order to hide the toolbar, you can either use setVisibility
or setImportantForAccessibility()
Description
•