Closed Bug 1570645 Opened 3 months ago Closed Last month

devtools panels registered by extension should provide an aria-label

Categories

(WebExtensions :: Developer Tools, defect, P1)

defect

Tracking

(firefox68 wontfix, firefox69 wontfix, firefox70 verified, firefox71 verified)

VERIFIED FIXED
mozilla71
Tracking Status
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- verified
firefox71 --- verified

People

(Reporter: pgrenier, Assigned: rpl)

Details

(Keywords: access)

Attachments

(4 files)

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.

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

Yura, where should this go in the Devtools product?

Component: Disability Access APIs → General
Flags: needinfo?(yzenevich)
Keywords: access
Product: Core → DevTools

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

Component: General → Developer Tools
Product: DevTools → WebExtensions

thanks for taking a look

Flags: needinfo?(yzenevich)

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?
Flags: needinfo?(pgrenier)

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.

Flags: needinfo?(pgrenier)

This was replicated by others using NVDA on Windows.

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies) → needinfo?(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.

Assignee: nobody → lgreco
Status: NEW → ASSIGNED
Flags: needinfo?(lgreco)
Priority: -- → P1
Summary: When using "CTRL+]" to select a custom add-on accessible name is "chrome://browser/content/webext-panels.xul" → devtools panels registered by extension should provide an aria-label
Pushed by luca.greco@alcacoop.it:
https://hg.mozilla.org/integration/autoland/rev/5e8f248009cf
devtools panels registered by extension should provide an aria-label. r=jdescottes
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Attached image 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”.
Flags: needinfo?(lgreco)
Attached image Screenshot 2.png

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).

Flags: needinfo?(lgreco)

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.

Status: RESOLVED → VERIFIED

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:
Attachment #9090398 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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.

Attachment #9090398 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

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.

You need to log in before you can comment on or make changes to this bug.