Open Bug 1523034 Opened 6 years ago Updated 3 years ago

Extension badge popups aren't accessible in flat review

Categories

(Core :: Disability Access APIs, defect, P2)

Product:
Core
Component:
Disability Access APIs
Version:
64 Branch
Type:
defect

Tracking

()

People

(Reporter: 166291, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

Steps to reproduce:

  1. Start Orca
  2. Open Firefox
  3. Install NoScript
  4. Open a wikipedia article
  5. Hit Ctrl+L to focus the address bar
  6. Use flat review to find the 'NoScript' button (I did this by hitting Insert+L)
  7. Use flat review to click the button (I did this by hitting Insert+7)

Actual results:

I'm alerted that the popup has finished loading then Orca starts reading the page I was viewing. Tabbing through NoScript's options works, but reading using flat just says 'Menu bar'

Expected results:

Flat view should read the text in the popup.

Component: Untriaged → Disability Access
Blocks: orca
Component: Disability Access → Disability Access APIs
Product: Firefox → Core

This could perhaps be fixed by bug 1487065, but needs re-testing once that lands.

I tried the patch listed in that bug on top of a tip from a few days ago, no difference.

I did some more testing: If you keep reading the address bar after the button all the contents for the NoScript panel shows up. It sounds like the contents are just more buttons on the menu.

So I'm a little confused. When I activate the NoScript panel, it appears beneath the address bar. And it looks like a bunch of clickable objects (similar to buttons). Orca's flat review feature is designed to give a flat, spatial representation of what is on the screen. Because the panel is below the address bar, what you describe sounds correct. Can you please explain how it isn't?

Related aside: This no-script extension is emitting object:state-changed:busy false when it appears. Orca was bogusly doing a SayAll of the underlying page at that point. I've just fixed that in Orca master.

Well, how am I supposed to know what's part of the extension and what's part of the page?

Right now Orca does limit flat review to window-like containers (windows, frames, dialogs, and menus). But it does not do so for other containers, including web pages. For instance, you can flat review out of a web page and move up to the address bar and from there to the menu bar without Orca stopping you. This is intentional.

Flat review is not meant to be an interaction model. It's a means to get a representation of what is physically showing on the screen, and a workaround for things which are not ideally accessible. For instance, I think one should be able to interact with all the push buttons on either side of the location bar in Firefox without having to use flat review or a mouse to click on stuff. But I don't see any way to do so. :(

Similarly, what would be great is if these extensions were easily keyboard navigable. Then you could use Orca's focus tracking, complete with context presentation to know when you're entering and leaving things. And sighted users would be able to interact with these extensions without having to use a mouse.

Without flat review there's no way to get Orca to read these popups even if you have keyboard navigation.

If F6 doesn't switch to the popups, fixing that in Firefox would also be helpful)

F6 switches to the popups but they aren't read

Aha. So it seems that pressing F6 does draw a (hard-to-see) focus rectangle around the popped-up NoScript extension. But then pressing Tab does nothing. Unless I'm missing something, sighted users who cannot use a mouse would also have a hard time interacting with that extension. Dunno if that should be addressed within Firefox itself or by the extension writer. But I'll let Marco answer that.

AFAIK, that part of the UI is completely controlled by the extension author. We provide the popup itself, but all the items within must be semantic HTML, or ARIA with JavaScript, to be navigable via keyboard, and proper CSS for focus visibility etc.

I tested this with another extension earlier (uBlock Origin) and found that while I couldn't focus the elements within the popup, if I opened the moz-extension://.../popup.html in another tab I could focus the elements using tab

(In reply to Joanmarie Diggs from comment #6)

I think one should be able to interact with all the push buttons on either side of the location bar in Firefox without having to use flat review or a mouse to click on stuff.

This is now possible. See bug 1436086.

(In reply to 166291 from comment #12)

I tested this with another extension earlier (uBlock Origin) and found that while I couldn't focus the elements within the popup, if I opened the moz-extension://.../popup.html in another tab I could focus the elements using tab

When you press the button to open an extension popup, the popup should get focus automatically. I haven't tested this with these specific add-ons, but it works here on Windows with Lastpass and Tampermonkey. I'll have to try this with the add-ons you mention.

Can you please try this with the new toolbar keyboard navigation in Firefox beta or nightly? Focus the address bar, tab to the Library button, then use the right arrow to locate the button for your extension and press space to activate it. Does anything get focus when you do this?

Flags: needinfo?(166291)
Priority: -- → P3

Still unable to focus it. I tried this with NoScript, uBlock Origin.

Flags: needinfo?(166291)

I usually can't reproduce this myself (though I think I've seen this rarely before). However, this has also been reported by an NVDA user: https://github.com/nvaccess/nvda/issues/9552
I guess there must be some timing issue involved here.

I am the user from an NVDA issue mentioned above. It is still happening for me with Nightly 70.0a1 (2019-07-30) (64-bit). Is there anything which I can do to help fix it?

I just tested this again and I saw it the first time I tried, but not the second. Something intermittently weird is going on here. I'll try to dig into it.

Marco, were you saying you see this with 1Password as well? Do you see it with other extensions as well? When this occurs and you press f6 repeatedly to try to find the panel, do you get a blank spot; i.e. where pressing f6 says nothing?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mzehe)
Priority: P3 → P2

Yes, I see this with TamperMonkey, too. Just ran into it yesterday. And F6 can then get stuck indeed, in the main document and not return to the toolbars. And never to the panel. So even if F6 toggles between the toolbar and the document, and the panel is open (checked with the mouse), it never is focused with F6. Nor does tabbing into it work.

Flags: needinfo?(mzehe)

(In reply to Marco Zehe (:MarcoZ) from comment #19)

Yes, I see this with TamperMonkey, too. Just ran into it yesterday. And F6 can then get stuck indeed, in the main document and not return to the toolbars. And never to the panel.

My hypothesis is that f6 is actually focusing the panel, but a11y isn't handling this properly for some reason, so you get nothing with a screen reader. I'm fairly sure this is a core a11y problem.

Filed bug 1570848 for the issue on Windows, since this is failing in Windows specific code. I still don't understand why this is failing on Linux.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.