== Issue
Arising from T342395, Codex should follow the best approach or making Dialog keyboard and screenreader accessible. Premises:
- When the dialog is first opened, the **focus is set** in a place that makes it easy **to access the content in the rest of the dialog**, and it's **impossible to navigate elements behind the dialog**.
- The dialog is **closable via keyboard**
=== Developer notes
**ARIA roles and attributes**
- While `aria-modal="true"` removes requirement of putting `aria-hidden` on background content, as the `aria-modal` informs assistive technologies that content outside a dialog is `inert`, it's the [[ https://a11ysupport.io/tech/aria/aria-modal_attribute | safer way currently ]] to have both attributes in use on the dialog and the background content elements.
**Keyboard navigation**
- The escaping of dialogs by pressing {key esc} (ESC) has already been part since the original Dialog implementation.
**Focus management**
- Putting the dialog element at end of body so it is not (mistakenly) a descendant of any element that has `aria-hidden` set to `true`. See also conversation in T343476#9078810 following.
=== Resources
[[ https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ | ARIA authoring practices on modal dialog ]] and specifically on [[ https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/#keyboardinteraction | focus trapping ]]
More on focus management:
https://allyjs.io/tutorials/accessible-dialog.html#reacting-to-kbdtabkbd-and-kbdshift-tabkbd
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role#focus_management
== Acceptance Criteria
[ ] Add `aria-modal="true"` to the already implemented `role="dialog"` element.
[ ] Focus on initial dialog open should work in a predictable way.
[ ] Users should not be able to interact with content behind the dialog when open.
[] Keep focus trap as initially implemented
[] Rely on `aria-hidden="true"` thank to its wider support over only `aria-modal` on background elements for all direct `body` children incl `script` tags
[] Add `inert` as future-facing attribute for non-interactable background elements
[x] ~~The user should always have a way to exit the dialog using keyboard navigation.~~ Established in initial implementation