A11y hierarchy for print dialog causes extraneous/strange screen reader verbosity
Categories
(Toolkit :: Printing, defect, P2)
Tracking
()
People
(Reporter: Jamie, Assigned: Jamie)
References
Details
(Keywords: access, Whiteboard: [print2020_v81])
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
STR (with the NVDA screen reader):
- Open any web page.
- Press control+p.
- Expected: NVDA says: "Print dialog, Destination"...
- Actual: NVDA says: "dialog, Print grouping, Destination"...
This can be fixed by:
- 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.
- Put role="dialog" on the body of the print modal document.
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
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)
Assignee | ||
Comment 2•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 4•5 years ago
|
||
bugherder |
Assignee | ||
Comment 6•5 years ago
|
||
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.
Comment 7•5 years ago
|
||
Comment on attachment 9171599 [details]
Bug 1660365: Fix a11y dialog role placement for the Print modal.
Approved for 81.0b5.
Comment 8•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
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.
Updated•2 years ago
|
Description
•