dialog/accessibility

17 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Dialog accessibility: modal announcement and naming

Modal dialogs must be clearly announced as dialogs by screen readers. Modal dialogs need to have an accessible name that informs the user of the purpose of the dialog. Generally, this accessible name should be presented visually as the title of the dialog. The title should concisely describe the contents or purpose of the modal.

Dialog accessibility: focus management on open

When a modal dialog is opened, focus must be programmatically moved into the dialog. In most cases, the first focusable control inside the dialog should receive focus.

Dialog accessibility: focus trapping

Once inside the modal dialog, focus must remain in the dialog - users must be prevented from navigating out of the dialog and back into the underlying page.

Dialog accessibility: hiding background content from screen readers

The underlying page behind the modal dialog must be hidden from screen readers, to avoid users accidentally navigating out of the dialog (for instance, using browse mode or heading navigation).

Dialog accessibility: close mechanism

Dialogs must have a way to be closed by the user. In most cases, this functionality will be provided as an explicit graphical "X" close control, though depending on the purpose of the dialog, users may instead have to activate more specific controls (such as "OK" / "Cancel" buttons).

Dialog accessibility: focus return on close

When a dialog is closed, focus returns to the most logical location in the page – in general, this is the trigger control that originally opened the dialog.

Dialog accessibility: required components

Dialog's title and close button are required to ensure an accessible experience for everyone. Keyboard and focus behavior must be considered.

Dialog keyboard: trigger elements and Esc key

Dialogs are initially hidden and can be opened by an element with role="button", called a trigger. Dialogs must be fully functional using the keyboard and assistive technology. Pressing Esc must dismiss a dialog, also returning focus to the trigger that opened it.

Dialog keyboard: focus management and Tab cycling

When a dialog is opened, the first interactive element (typically the close button) is focused. For a scenario like a command palette with an input next to the close button, the input will receive focus first. Hitting Tab will cycle through all interactive elements within the dialog. To escape the focus trap, hitting the Esc key or clicking on the backdrop will close the dialog. While the dialog is open, page scrolling is disabled and becomes inert.

Dialog accessibility: live region placement

Use extra caution when utilizing a live region that exists outside of the Dialog component. This is because some browser and screen reader combinations may ignore the live region entirely if it does not already exist within the dialog. If you need to use a live region while a dialog is active, place the live region within the dialog, rather than outside of it.

Dialog accessibility: Rails implementation features

The Rails version of the component generates a dialog element with aria-modal="true". By default, the generated dialog includes an "X" graphical close control, which receives focus automatically when the dialog is opened. In the Rails version, you can use the autofocus property on interactive elements in the dialog's content to move the initial focus directly to a specific control. Focus is maintained inside the dialog. When the dialog is closed, focus is automatically moved back to the last element in the underlying page that had focus.

Dialog accessibility: React implementation features

The React version of the component generates a div element with role="dialog" and aria-modal="true". When provided, the title prop for the component is rendered as an h1 heading and is explicitly referenced by the dialog using aria-labelledby to provide an accessible name for the dialog.

Dialog accessibility: heading and aria-labelledby

When provided, the title prop for the component is rendered as an h1 heading and has an id attribute. This id is referenced from the dialog container itself with aria-labelledby to provide an accessible name.

Dialog accessibility: integration test requirements

Integration tests must verify that: (1) The modal dialog has a sufficiently descriptive title rendered as a heading rendered as an h1 heading. (2) Once the dialog is closed, focus is returned to the most appropriate location in the page.

Dialog accessibility: component test requirements

Component tests must verify that: (1) The modal dialog programmatically exposes its role - either using dialog or role="dialog". (2) The modal dialog programmatically conveys that it is modal with aria-modal="true". (3) The title prop of the component is rendered as an h1 heading, that it has an id attribute, and that this id is referenced from the dialog container itself with aria-labelledby. (4) When the modal dialog is opened, focus is moved into the dialog - generally, to the first focusable control inside the dialog. (5) In the Rails implementation, the control specified by the author with autofocus receives focus when the modal dialog is opened. (6) Focus remains inside the dialog - using Tab/Shift+Tab must not result in focus landing in the underlying page. (7) When the modal dialog is closed, focus is returned to the last element in the underlying page that was focused at the time the dialog was opened - typically, the trigger element that opened the dialog.

Dialog implementation requirement: descriptive title

Make sure to provide a sufficiently descriptive title for the modal dialog. The title should concisely describe the contents or purpose of the modal.

Dialog implementation requirement: focus handling when trigger missing

In cases where the original trigger element that opened the dialog is not present in the page any more, or where the dialog was not opened as a result of a user action, you will need to explicitly handle which element will receive focus programmatically once the dialog is closed.

Give your agent this brain