Closed Bug 1660365 Opened 4 years ago Closed 4 years ago

A11y hierarchy for print dialog causes extraneous/strange screen reader verbosity


(Toolkit :: Printing, defect, P2)




82 Branch
Accessibility Severity s4
Tracking Status
firefox81 --- verified
firefox82 --- verified


(Reporter: Jamie, Assigned: Jamie)



(Keywords: access, Whiteboard: [print2020_v81])


(1 file)

STR (with the NVDA screen reader):

  1. Open any web page.
  2. Press control+p.
    • Expected: NVDA says: "Print dialog, Destination"...
    • Actual: NVDA says: "dialog, Print grouping, Destination"...

This can be fixed by:

  1. Removing role="dialog" from hbox.dialogBox. One concern is that I think this is in common template code used by other browser TabDialogBox implementations, so we'd need to adjust those too.
  2. Put role="dialog" on the body of the print modal document.
Blocks: 1657994, 133787
Severity: -- → S4
Priority: -- → P2
Whiteboard: [access-s4] → [access-s4][print2020_v81]

Testing note: Concerning other dialogs that use the same template, Gijs explained on matrix:

you can run a simple test using the browser console and something like:  Services.prompt.alertBC(gBrowser.selectedBrowser.browsingContext, Ci.nsIPrompt.MODAL_TYPE_TAB, "Hi", "Hi") 
(two final params are the title and message strings, depending on what you're doing it may be worth varying those)

Previously, the browser dialogTemplate contained role="dialog" and the Print modal body had no role.
This caused screen readers to extraneously report "dialog, Print grouping".
Dialogs presented with commonDialog.xhtml (e.g. using Services.prompt.alertBC) did have the dialog role on the body, so screen readers would report "dialog, {dialogTitle} dialog".

To fix this, remove role="dialog" from dialogTemplate and instead put it on the body of the Print modal.
Now, screen readers report just "Print dialog" and "{dialogTitle} dialog", respectively.

The caveat with this change is that unless you use the XUL dialog element (which sets role="dialog" via JS), you must set role="dialog" on the body of the dialog page.
commonDialog.xhtml and selectDialog.xhtml use the XUL dialog element, so any dialogs using these are fine.

Assignee: nobody → jteh
Pushed by
Fix a11y dialog role placement for the Print modal. r=Gijs
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch

Reminder to request Beta approval.

Flags: needinfo?(jteh)

Comment on attachment 9171599 [details]
Bug 1660365: Fix a11y dialog role placement for the Print modal.

Beta/Release Uplift Approval Request

  • User impact if declined: Extraneous/strange verbosity for screen reader users in the new print modal.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simply adds (well understood) attributes that are picked up by the accessibility engine.
  • String changes made/needed: None.
Flags: needinfo?(jteh)
Attachment #9171599 - Flags: approval-mozilla-beta?

Comment on attachment 9171599 [details]
Bug 1660365: Fix a11y dialog role placement for the Print modal.

Approved for 81.0b5.

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

This issue is verified fixed using Firefox 82.0a1 (BuildId:20200907094115) and Firefox 81.0b7 (BuildId:20200906164749) on Windows 10 64bit with NVDA screen reader.

Flags: qe-verify+
Accessibility Severity: --- → s4
Whiteboard: [access-s4][print2020_v81] → [print2020_v81]
You need to log in before you can comment on or make changes to this bug.