1754094 - Modal HTML5 dialogs do not contain their tab sequence - cycles dozens of window stops before returning to the dialog

Status: NEW

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Thomas D. (:thomas8)]

Maybe someone intended this as a feature (?), but looking at wai-aria best practices, it does look like a bug.

• Feels extremely odd when pressing Tab on what looks like a modal dialog suddenly takes you on a tour of unrelated tab stops on the underlying window, instead of cycling just the modal dialog as it used to do since time immemorial.
• Also makes it impossible to close the dialog with Esc or main dialog button as long as focus is wondering about.
• Worse, due to another bug, all the close buttons on every open tab are now tab stops, so returning keyboard focus to the dialog using keyboard only may be non-trivial.

STR

1. Open a number of application tabs, or an even larger number of message tabs.
2. Open any modal dialog, e.g. from new Address Book, edit a contact, focus the profile picture, and press Enter to get the Add photo to contact dialog (which unfortunately doesn't have a title).
3. Press Tab with intention of cycling dialog options and buttons.

Actual

• If you're lucky and the dialog actually has focus (a focus ring somewhere in the dialog), pressing Tab a couple of times will remove focus from the modal dialog and start to focus a lot other spots in the underlying window:
  • status bar (bug 1754084)
  • all close buttons of all open tabs (as many as you may have) (fixed by Bug 1754097)
  • Spaces toolbar buttons
    Thus it's very hard to return focus to the dialog using keyboard, e.g. to reach its other options/buttons.

Expected

• Per https://www.w3.org/TR/wai-aria-practices/#dialog_modal, modal dialogs must contain their tab sequence, i.e. pressing tab must cycle only within the dialog.
• The modal dialog must retain focus within the content tab so that Esc will always close it
• I guess it's ok if Ctrl+page up/down and Ctrl+[Shift]+Tab continue to work for switching tabs

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

Yup, dialogs (modal or not) are meant to have their own focus cycle. Is there a reason the html:dialog default behaviour doesn't do this already? Maybe look at bug 840640

Comment 2

[Thomas D. (:thomas8)]

(In reply to Henry Wilkes [:henry] from comment #1)

Yup, dialogs (modal or not) are meant to have their own focus cycle. Is there a reason the html:dialog default behaviour doesn't do this already? Maybe look at bug 840640

Thank you Henry! I've asked for a comment on this problem in bug 840640 comment 59.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Thunderbird could trap the focus if needed with Chrome code.

Comment 4

[Thomas D. (:thomas8)]

Reporting back from bug 840640, following my enquiry in bug 840640 comment 59, there seem to be different opinions about what constitutes user hostile behaviour (see also relevant aria-practices discussion). As defined in the aria-specs, I maintain that for screenreader or keyboard-only users, allowing tab focus to go out from a modal dialog into chrome is highly confusing and disfunctional, and will typically break the UX - after all, the whole point of having a modal dialog is to force/focus on a decision before moving on. Access to chrome from modal dialog could still be possible with shortcuts like Ctrl+L, no need for tabbing out of the dialog.

(In reply to Emilio Cobos Álvarez (:emilio) from Bug 840640 comment #61)

That seems a bug about thunderbird, what am I missing? Modal dialogs trap focus from the pages point of view (makes everything else on the page inert). But we don't want to prevent the user from interacting with the browser chrome just because a page has called dialog.showModal, that'd be pretty user hostile.

Thunderbird can use dialog and it'd trap focus like dialogs trap focus on Firefox. Again, i feel like I'm missing something.