Modals, ajax and focus

[jamesjacobs]

Currently, modals that load content with AJAX require trapFocus() to be called on AJAX completion. This has been raised as an issue by product teams as has the list of allowed elements within the trapFocus method.

This has highlighted the wide variety of modals we have across products, such as:

1. Standard non-AJAX modals
2. AJAX modals with no header or footer that display a loading spinner
3. Ajax modals with a header and close X button that display a spinner
4. Modals without a close X button
5. Stacked modals
6. External lib modals (CK editor)
7. Ability to trigger a modal and turn off the backdrop - potentially meaning a user can click into an element behind the modal dialog.

Recommended action:

1. Perform an audit of all modals across product and document findings
2. Re-work ModalFocusService to check that element trying to gain focus is within the modal, rather than passing it a jQuery collection of the modal (to avoid having to call trapFocus on AJAX completion).
3. Decide if the ModalFocusService should control which elements can be focussed.

Related info:
https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/dialog-modal/js/dialog.js

[Stanton]

There are also non-Pulsar 'lightboxes' still in use in various older areas of the UI, this is a prime opportunity to unify the modal solution across products.

[Stanton]

From @james-manley

Calling trapFocus makes sense, but in reality that just adds more keydown handlers. We need to remove the old invalid ones as part of trapFocus().