feat: support modal behaviours

[jlp-craigmorten]

When a modal element is displayed, assistive technologies SHOULD navigate to the element unless focus has explicitly been set elsewhere. Some assistive technologies limit navigation to the modal element's contents. If focus moves to an element outside the modal element, assistive technologies SHOULD NOT limit navigation to the modal element.

REF: https://w3c.github.io/aria/#aria-modal

[jlp-craigmorten]

See also #44 (comment)

[jlp-craigmorten]

See also:

• https://a11ysupport.io/tech/aria/dialog_role
• https://a11ysupport.io/tech/aria/alertdialog_role
• https://a11ysupport.io/tech/aria/aria-modal_attribute

[jlp-craigmorten]

See also https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role#possible_effects_on_user_agents_and_assistive_technology

When the dialog is correctly labeled and focus is moved to an element (often an interactive element, such as a button) inside the dialog, screen readers should announce the dialog's accessible role, name and optionally description, along with announcing the focused element.

Though this is not normative, but MDN's opinion (with a disclaimer saying as such).

[jlp-craigmorten]

Raised #47 for dialog behaviours as this issue was originally for aria-modal behaviours, which though often comes hand in hand with role="dialog" behaviours, are distinct.

[jlp-craigmorten]

R.E.

When a modal element is displayed, assistive technologies SHOULD navigate to the element unless focus has explicitly been set elsewhere

Not sure how feasible this is, in part due to it's abiguity - what does "is displayed" mean in this context. Is it visible in the viewport, a particular CSS style change, in the DOM.

I guess we could look to use something like the isInaccessible() check for whether it's hidden from the accessibility tree, and if not, then navigate to it.

Clarity would also be needed in scenarios such as 2 modals being "displayed" at once. Presumably taking the first would be "good enough"?