Closed Bug 1657994 Opened 4 years ago Closed 4 years ago

Tab modal print UI a11y review

Categories

(Toolkit :: Printing, task, P1)

task

Tracking

()

RESOLVED FIXED
a11y-review passed

People

(Reporter: mstriemer, Unassigned)

References

Details

(Whiteboard: [print2020_v84])

Attachments

(1 file)

Bug 133787 is the meta bug for a new tab-modal print UI, this will include a preview and be on top of the current tab rather than being a system dialog or a preview that blocks all other interactions with the window.

Much of the expected functionality is now available by default in Nightly to be tested. Some features/settings are currently missing, and there are definitely a11y issues with the tab-modal-ness (you can still interact with the page, focus is not trapped).

Some guidance on the tab-modal would be good as to things we definitely want to avoid, listing those now could be good but several of them may already be on our list of things to do.

Attached image primary-mock.png

Description:

Unify the print and print preview flows into a single tab-modal style print dialog that includes a preview. Full mocks are available: https://mozilla.invisionapp.com/share/MFWMR6H5X3K#/screens/411381710

Users will be presented this new dialog when they attempt to print or begin a print preview of a page. This dialog is tab-modal which allows users to continue interacting with other tabs while the print/preview dialog is shown.

The primary screen is attachment 9168869 [details] (The Mozilla homepage is shown with a modal dialog over the page providing a print preview on the left and print setting options on the right. The number of sheets of paper to be printed is listed, along with options to select Destination, Copies, Orientation, Pages, Color mode, More setting, Print and Cancel)

How do we test this?

This UI is now enabled by default in Nightly, it is controlled by the print.tab_modal.enabled pref. The UI is triggered by the regular print or print preview methods (File > Print, Ctrl/Cmd+P, etc).

When will this ship?

Tracking bug/issue: bug 133787
Design documents (e.g. Product Requirements Document, UI spec): https://mozilla.invisionapp.com/share/MFWMR6H5X3K#/screens/411381710
Engineering lead: Mark Striemer
Product manager: Romain Testard

All user interface additions and changes must meet the Mozilla Accessibility Release Requirements:

https://wiki.mozilla.org/Accessibility/Requirements

Please describe the accessibility requirements you considered and what steps you've taken to address them:

The interface is using native HTML elements including labels as much as possible. Where extra widgets have been needed they've been added as styling over regular HTML elements rather than using divs, etc. Providing group labels as well as individual input labels. The XUL SubDialog component (currently in use in about:preferences) has been used for the dialog, but it is missing a11y features to be used at the chrome-level.

Describe any areas of concern to which you want the accessibility team to give special attention:

The tab-modal dialog and its interactions with the print preview appear to be a current pain point. I'm hopeful we can improve this quite a bit on our own but extra attention would be good for that portion of the feature.

a11y-review: --- → requested
Whiteboard: [print2020]
Depends on: 1659467
Depends on: 1658445
Depends on: 1659877
Depends on: 1653317

Thanks for requesting a11y review and providing all of these details. They're very helpful.

Some initial comments:

(In reply to Mark Striemer [:mstriemer] from comment #0)

Some features/settings are currently missing, and there are definitely a11y issues with the tab-modal-ness (you can still interact with the page, focus is not trapped).

This is probably the biggest a11y concern right now. It's possible for the user to tab out of the modal and into the document, which is going to be very confusing for some users. It's also possible to shift+tab out of the settings and into the preview, where you get stuck. I don't know anything about TabDialogBox, but I'm hoping it will fix some of this (bug 1653317).

Worse, when you get focus into print preview, the print preview doesn't get exposed to a11y at all, so a screen reader user just gets nothing reported at all. I don't think this is a new bug - it seems to be broken with the existing print preview as well - but it's a lot worse with the new modal because you can shift+tab/f6 to it from the new print settings.

I've marked some other bugs as blocking this one.

One minor issue is that in the a11y tree, we see unlabelled dialog -> "Print" grouping. I'd prefer to just see "Print" dialog. That's an easy fix and I have a patch locally, but moving to TabDialogBox will probably change how this has to be implemented (or maybe just fix it?), so it's probably worth waiting on that.

Depends on: 1660359
Depends on: 1660363
Depends on: 1660365
Depends on: 1660400
Depends on: 1660951
Depends on: 1661382

I think we're done here. Thanks. Please request a11y review on any significant changes that are made to this UI.

Status: NEW → RESOLVED
a11y-review: requested → passed
Closed: 4 years ago
Resolution: --- → FIXED
Whiteboard: [print2020] → [print2020_v84]

Migraine trigger is migraine trigger. Bug 1692100. It has the preview scroll separate from the background.

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

Attachment

General

Created:
Updated:
Size: