Change Details

== 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. This is most simple when teleported dialogs are the way to go, see related discussion at T343476 **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 [x] 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

== 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. This is most simple when teleported dialogs are the way to go, see related discussion at T343476 **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 [x] Add `aria-modal="true"` to the already implemented `role="dialog"` element. [x] Focus on initial dialog open should work in a predictable way. [x] Users should not be able to interact with content behind the dialog when open. [x] Keep focus trap as initially implemented [x] 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 [x] 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

== 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. This is most simple when teleported dialogs are the way to go, see related discussion at T343476 **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 [x] Add `aria-modal="true"` to the already implemented `role="dialog"` element. [ x] Focus on initial dialog open should work in a predictable way. [ x] Users should not be able to interact with content behind the dialog when open. [x] Keep focus trap as initially implemented [x] 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 [x] 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