---
url: /components/dialogs/accessibility.md
description: >-
Dialogs provide important prompts in a user flow. Use dialogs to make sure
users act on information
---
# Dialogs
Dialogs provide important prompts in a user flow. Use dialogs to make sure users act on information
[Overview](overview.md) · [Specs](specs.md) · [Guidelines](guidelines.md) · **Accessibility**
## Use cases
People should be able to use assistive technology to:
* Open and close a dialog
* Provide and submit other inputs if the dialog is interactive, such as a [text field](../text-fields/overview.md "Text fields let users enter text into a UI.") or selectable [list](../lists/overview.md "Lists are continuous, vertical indexes of text and images.")
* Scroll the dialog to access all of its contents if that content extends beyond the container of the dialog
## Interaction & style
### Use sparingly
Dialogs are purposefully interruptive. This means they appear in front of app content and disrupt the flow of content for people who may, for example, be using a screen reader to navigate the page.
As such, dialogs should be used sparingly and only to provide critical information. Less critical information should be presented in a non-blocking way within the flow of app content.
::: tip Do
Present non-critical information using other UI within the flow of app content
:::
::: danger Don't
Avoid putting non-critical information in a dialog
:::
### 200% text size
Avoid excessive text wrapping or truncation by choosing concise strings.
On Android, headlines should be kept concise enough to fit within **four** lines after the text size is increased to 200%. If a headline exceeds this limit and gets truncated, provide an alternative way to access the full content in a single tap.
::: warning Caution
Avoid excessive text wrapping or truncation by choosing concise strings
:::
### Elements within dialogs
Because dialogs can contain various elements within them, refer to the relevant [accessibility](../../foundations/overview/principles.md "Accessible design makes products usable for people with all kinds of abilities.") guidelines for each element.
Some common examples include:
1. [Text fields](../text-fields/overview.md "Text fields let users enter text into a UI.")
2. [Typography](../text-fields/accessibility.md "Material's typography follows a type scale with accessibility considerations baked in.")
3. [Buttons](../buttons/overview.md "Buttons let people take action and make choices with one tap.")
Full-screen dialogs can contain various elements such as (1) text fields, (2) typography, and (3) buttons, which each may have their own accessibility guidelines
## Initial focus
When a dialog appears, focus should automatically land on the first interactive element within the dialog.
Initial focus lands on the first interactive element within a dialog. The tab key moves focus through the next interactive elements in a cycle.
The shift and tab keys together move focus in the opposite direction. The space or enter key triggers or commits the action of the focused element.
## Keyboard navigation
| Keys | Actions |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Tab | Focus lands on the next interactive element contained in the dialog, or the first element if focus is currently on the last element |
| Shift + Tab | Focus lands on the previous interactive element contained in the dialog, or the last element if focus is currently on the first element |
| Space or Enter | Triggers or commits the action of the [focused](../../foundations/interaction/states/applying-states.md#bfc1624f-6bcc-4306-b0c1-425e2d8a1bf9 "A focused state communicates when a user has highlighted an element, using an input method such as a keyboard or voice.") element |
| Escape | Closes the dialog |
## Labeling elements
The [accessibility](../../foundations/overview/principles.md "Accessible design makes products usable for people with all kinds of abilities.") label for a dialog is typically the same as the dialog’s title or headline.
On web, basic dialogs should have the **alert dialog** role.
Basic dialogs are known as alert dialogs on web
Components contained within the dialog, such as buttons, should be labeled according to the guidelines specific to those components.
For common examples, see:
* [Buttons](../buttons/specs.md "Buttons let people take action and make choices with one tap.")
* [Text fields](../text-fields/overview.md "Text fields let users enter text into a UI.")
Elements within a dialog should be labeled according to their guidelines