1820765 - Cannot browse role="document" panels (anti-tracking and site information) with Orca

Status: NEW

(Firefox :: Disability Access, defect)

Description

[Henry Wilkes (they/them) [:henry-x]]

Orca recently fixed a issue with the anti-tracking and site information panels, which use role="document". Before, pressing the arrow keys with focus within the panel would cause Orca to navigate and read the web page document. See https://gitlab.gnome.org/GNOME/orca/-/issues/293.

With the latest development tip, Orca will now no longer browse the web page document, and instead all arrow key events will pass to firefox instead. So it is possible to move within the panels as if in "focus mode".

However, it is still not possible to navigate the panels in "browse mode".

As detailed in the Orca bug:

if Mozilla wants something to be browse-mode-able in Orca:

1. It needs to have the DOCUMENT_WEB role rather than the DOCUMENT_FRAME role.
2. The AtkRelation set of the FRAME will need to point to that popup as the embedded document; not the actual, displayed web page.

Steps to Reproduce

With Orca's current development tip:

1. Enable Orca screen reader.
2. Open firefox.
3. Enter https://example.org.
4. Navigate to the "anti-tracking" button prior to the URL entry (F6, Shift+Tab).
5. Press Enter to open popup panel.
6. Enter "browse mode".
7. Press an arrow key.

Result

The anti-tracking panel is not navigated as in browse mode. The work around to read the non-focusable components is to use read-all or flat review.

Expect

To be able to navigate the anti-tracking panel in browse mode like in NVDA.

NOTE: Other panels that do not use role="document", like the bookmarks panel, are not browe-mode-able, but this is expected and the same in Orca as NVDA.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

I wasn't sure if this should go in the "Disability Access APIs" component because I'm not sure if there needs to be a change in the access core, or if the solution is to implement the panels in a different way, like using xul:browser rather than a role="document".

Comment 2

[James Teh [:Jamie]]

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #0)

As detailed in the Orca bug:

I tried to comment on the Orca bug, but ran into problems with the signup process. Emails from Gnome GitLab don't seem to be getting to me. :( Needinfoing Joanie, but if she doesn't respond, I'll try Gnome GitLab again at some point.

1. It needs to have the DOCUMENT_WEB role rather than the DOCUMENT_FRAME role.

I can do that, but that would make role="document" inside normal web pages also get exposed as DOCUMENT_WEB (so there'd be nested DOCUMENT_WEB in that case). Is that desirable/expected for Orca?

2. The AtkRelation set of the FRAME will need to point to that popup as the embedded document; not the actual, displayed web page.

This one is trickier. The relation on the frame is supposed to point to the primary (tab) document. The pop-up panel isn't the primary document, but it is the document the user is interested in when they open that panel.

Given that Orca walks the focus ancestry anyway, why does it look at the relation to get the browse mode document? I'm sure there's a good reason, just trying to understand.

I guess we could fudge the relation temporarily for ATK when focus goes inside one of those panels.

This does make me wonder whether browse mode works for web extension panels, though. I thought someone said it did, but I don't see how it could if Orca relies on the frame relation.

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #1)

I wasn't sure if this should go in the "Disability Access APIs" component because I'm not sure if there needs to be a change in the access core, or if the solution is to implement the panels in a different way, like using xul:browser rather than a role="document".

Using xul:browser would fix the role, but it wouldn't fix the relation. It probably also isn't practical for at least some cases.

Comment 3

[Joanmarie Diggs]

Orca doesn't always ascend the hierarchy to get the document. Sometimes it's looking from the top down because:

• focus isn't in the document.
• there's a load-complete event from a document that might not be showing (if memory serves me the new tab page does, or at least used to do, that)
• the user has multiple tabs open, and a page in the non-active tab is firing live region events. The user's setting is to fire live region events from the active document even if focus is not in that application. So we need to know what the active document is even though we're in, say, Thunderbird.

The embeds relationship is super handy and efficient for these scenarios.

I don't believe browse mode works for web extension panels. Though I could be wrong.

As for document web inside document web, we already have that scenario for embedded documents (e.g. iframe). So.... While I'm not positive, my guess is that in the scenario in question, where focus is programmatically moved to the popup by not Orca, Orca would just ascend the hierarchy, say "yup, focus is in a browse mode document" and innocently trust that it was correct when the user pressed down arrow. grins Worth a try build for Henry to test, if it's not too much trouble.

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

I don't believe browse mode works for web extension panels. Though I could be wrong.

I was able to browse the extension panel. Steps with Orca (43.1) and firefox tip:

1. Install https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/
2. Navigate to the "Extensions" menu button in the toolbar.
3. Select the addon "Snowflake".
4. Focus enters the .webextension-popup-browser and the first line is read out.
5. Orca is by default in "focus" mode, so manually switch to "browse".
6. Press down arrow to browse.

I imagine it would work with other extensions as well, if you want to install something else.