Overlay

Accessibility and usability expectations

Presentation

Cognition

• The styling for the Overlay should make it clear, which elements are within the scope of the component
• So that the dialog's purpose is clear, items in the dialog should be related to each other in their purpose/general functionality

Vision

• For text content in the activating control, as well as inside the dialog, it must have a color contrast ratio of at least 4.5:1
• If using icons, for example to label the activating control, they must have a color contrast ratio of at least 3:1 against the background color

Mobility

• To help people easily navigate to the dialog when it is triggered, focus must move appropriately, for example to the first interactive element inside the dialog
• The dialog's controls should not receive focus when hidden and not visible
• Focus must not move to content that is hidden or obscured by the dialog
• When a user collapses the dialog, focus should return to the dialog's activating control
• The dialog's activating control, and interactive controls in the dialog must have a target size of at least 24 by 24 pixels

Adaptability

• Make sure that component can be increased up to 200%, and any content remain visible, and that the dialog is not clipped or hidden
• The dialog’s content must remain readable and not require horizontal scrolling to read or operate it, at a viewport size of 320 by 256 CSS pixels
• When adding additional text spacing, make sure that dialog's activating control and content can still be read in its entirety, and that the dialog is not clipped or hidden

Interaction

Keyboard

• Ensure that the activating control receives focus, and can be activated using only a keyboard
• There should be an easy way to dismiss the dialog and return to the trigger control, for example, using the "Escape" key

Touch and mouse

• The dialog must be activated on the up event, and not the down event, or there must be a way to prevent the action from taking place on the down event

Engineering for compatibility with assistive technology

Screen reader

• When the dialog is hidden and not visible, content inside of it should not be announced by screen readers
• A aria-haspopup="dialog" attribute should be provided, to help convey to people that the activating control opens a dialog
• Simple confirmation-style dialogs which have a heading, a small amount of text (usually a single paragraph) and one or two controls that require action, should use an aria-describedby attribute that references the content after the main heading. This way, when the first interactive control in the dialog receives focus, both the accessible name and the accessible description will be announced by a screen reader before the element that receives focus is announced. This simplifies the experience for both screen reader and keyboard users as they can immediately interact with the call to action elements

Speech recognition

• The activating control must include the visible label in their accessible names, to help people using voice control software to interact with them

Built-in accessibility features

By default, the Overlay component has two key built-in accessibility features:

The first is that, when the Overlay is expanded, focus is automatically moved to the first interactive element in the dialog, as expected. If there's a more suitable control, of if the Overlay is sufficiently complex, to the point where it would make sense to move focus to the Overlay itself, this target can be changed using the initialFocusRef prop.

The second is that the Escape key can be used to dismiss the Overlay, when either the activating control, or one of it's children has focus. When dismissed, focus is returned to the activating control by default.

Implementation requirements

The Overlay must have an accessible name, which should be provided using an aria-label attribute. The accessible name should describe the purpose of the component. Where Overlays have a heading, the accessible name might mirror this.

The component also needs a role to convey its type, and how people can expect to interact with it. In most cases, this will probably be role="dialog". However, where the Overlay includes action lists, and represents more of a traditional desktop menu, this should be set to role="menu".

How to test the component

Integration tests

• When the Overlay is visible, focused controls in the rest of the page aren’t obscured or hidden by the dialog

Component tests

• The Overlay has an appropriate role of either dialog or menu
• The Overlay has an appropriate accessible name
• When the Overlay's activating control is interacted with, focus moves to an appropriate control within the Overlay, such as the first focusable element
• When dismissing the Overlay, focus must return to the activating control
• The Overlay component must have at least one keyboard accessible method of closing them, for example:
  • A keyboard accessible 'close' button
  • Closing when the Escape key is pressed