1570645 - devtools panels registered by extension should provide an aria-label

Status: VERIFIED FIXED

(WebExtensions :: Developer Tools, defect, P1)

Description

[Paul Grenier]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Steps to reproduce:

1. Add an add-on. Any add-on seems to have this problem. It can be added from the store or in debug mode from a local file.
2. Turn on a screenreader (issue appears in VO, NVDA regardless of OS).
3. Navigate to a page.
4. Open devtools using keyboard.
5. Select the new add-on with "CTRL+]"

Actual results:

Observe accessible name is "chrome://browser/content/webext-panels.xul" and not the correct button name or panel title.

Expected results:

The accessible name should be the same as if the add-on was selected using TAB or mouse click. When using the "TAB" key to select the add-on, the accessible name is correct.

Comment 1

[Marco Zehe (:MarcoZ)]

Yura, where should this go in the Devtools product?

Comment 2

[Patrick Brosset <:pbro>]

This might be better triaged in the WebExtensions/DevTools component. Moving there.

Comment 3

[Yura Zenevich [:yzen] (please use "needinfo")]

thanks for taking a look

Comment 4

[Alex Cornestean]

Hello,
I have attempted to reproduce the issue based on the STR you have provided but it is not clear whether I completely understand what actions you have performed in order to achieve the results. As such I would like to ask of you the following:

1. “4. Open devtools using keyboard.” - what exactly are the devtools you are referring to and what is the keyboard shortcut combination you used to open them?
2. “5. Select the new add-on with "CTRL+]"” - can you please provide a video of how you perform this step?
3. Also, for further clarification, could you attach a video of the whole reproduction process?

Comment 5

[Paul Grenier]

Alex,

1. On Mac, I'm using "Command (⌘) + Option + i" to open devtools.
2. Without pressing any additional keys, the devtools gains focus from the previous step. (on a Mac) pressing "Command (⌘) + ]" (right bracket) will move the selected "tab" in devtools to the right.

The observation is that native tabs announce their names while add-ons do not. This is different when TAB key is used to change focus and select a tab.

Comment 6

[Paul Grenier]

Attachment: Screen Recording 2019-08-14 at 11.22.53 AM.mov

This was replicated by others using NVDA on Windows.

Comment 7

[Alex Cornestean]

Hello,

Based on the new provided information, I have managed to successfully reproduce the issue on the latest Nightly (70.0a1/20190815193505), Beta (69.0b13/20190812173625) and Release (68.0.1/20190813150448) under Windows 10 Pro 64-bit and macOS High Sierra 10.13.6.

Selecting the “Axe Developer Tools” panel from the devtools window using “CTRL+]” on Windows or “Command (⌘) + ]” on Mac will incorrectly output “chrome://browser/content/webext-panels.xul” instead of the button or panel name when using NVDA screen reader or the VO feature.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

I just looked into this, it is definitely an WebExtensions DevTools API issue (and so it is currently filed in the right bugzilla component).

To fix the issue the panels registered by extensions using the WebExtensions devtools APIs should provide an aria-label attribute, which is what the screenreaders use to get a user-friendly name for the devtools panels.

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1570645 - devtools panels registered by extension should provide an aria-label. r?jdescottes!

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5e8f248009cf
devtools panels registered by extension should provide an aria-label. r=jdescottes

Comment 12

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/5e8f248009cf

Comment 13

[Alex Cornestean]

Attachment: Screenshot 1.png

Hello,

Verified the fix using the latest Nightly (71.0a1/20190908214439) under Windows 10 Pro 64-bit and macOS High Sierra 10.13.6.

While the VO feature on macOS will properly output the name of the “Axe Developer Tools” panel (it will output “axe, frame”), there are some issues with the rest of the panels:

• selecting the Inspector panel will output “Firefox Nightly busy”.
• selecting Console will output “text blank, main”.
• selecting Network will list several items but not output the actual name of the frame or panel.
• Style Editor will output a disclaimer line from the Mozilla Public License (“This Soruce Code Form is subject...).

On Windows, NVDA screen reader will have the following behavior:

• while moving the selection with “Ctrl+]”, inconsistent output is observed: the “Memory” and “Storage” panel names are not output on the first try, only after cycling back and forth a couple of times.
• when the selector reaches the “Axe Developer Tools” panel on the first attempt, the screen reader outputs what is highlighted in screenshot 1. After a couple of passes, NVDA will output what is highlighted in screenshot 2. On other several occasions, NVDA will output “axe document” and “blank”.

Comment 14

[Alex Cornestean]

Attachment: Screenshot 2.png

Comment 15

[Luca Greco [:rpl] [:luca] [:lgreco]]

None of the natively integrated devtools panels (e.g. Inspector, Console, Network, Style Editor etc) has been changed in the patch landed from this bugzilla issue, and so the behaviors described in comment 13 (e.g. what the screenreader outputs when the Console or the Style Editor is selected) are very likely related to some other pre-existing accessibility issues, unrelated to the "extension registered" devtools panels (and so the same kind of behavior should be reproducible even before the change applied in this bugzilla issue).

The main goal of the fix landed from this bug is to avoid that the devtools panels registered by the extensions are all going to be seen as "chrome://browser/content/webext-panels.xul" by the screenreaders, but this doesn't exclude that there may be other "devtools toolbox" accessibility issues that are not specific to the "extension registered" devtools panel (and so also not affected nor fixed by this particular change).

Comment 16

[Alex Cornestean]

Hello and thank you for the quick response!
Considering the objective of the fix was for screen readers to output something different from "chrome://browser/content/webext-panels.xul" when selecting devtools panels registered by extensions, which they are now, the fix is confirmed. Will close this issue as a result.

Comment 17

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 9090398 [details]
Bug 1570645 - devtools panels registered by extension should provide an aria-label. r?jdescottes!

Beta/Release Uplift Approval Request

• User impact if declined: Without this fix all the devtools panels registered by extensions are not accessible, from a screenreader point of view all the panels will all be seen as "chrome://browser/content/webext-panels.xul" instead of the panel title.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Same STR used to verify it on Nightly.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch isn't a risky one, the actual fix is a single line change (which adds the missing property used to set the aria label) and it is explicitly tested by the test case added in the same patch (which is also the majority of the patch).
• String changes made/needed:

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9090398 [details]
Bug 1570645 - devtools panels registered by extension should provide an aria-label. r?jdescottes!

Fix for a11y issue, verified in Nightly, OK for uplift for beta 7.

Comment 19

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d586c535354f

Comment 20

[Alex Cornestean]

Hello,

Verified the fix using the latest Beta (70.0b7/20190916074538) under Windows 10 Pro 64-bit and macOS High Sierra 10.13.6.

Screen readers output lines different from "chrome://browser/content/webext-panels.xul" when selecting devtools panels registered by extensions, confirming the fix.