The text of this dialog describes design considerations for initial focus and accessible descriptions in dialogs with large amounts of text.When the dialog closes, to maintain the user's point of regard, focus returns to the Verify Address button.To support screen reader user awareness of the dialog text, the dialog text is wrapped in a div that is referenced by aria-describedby.
Initial focus is set on the first paragraph because the first interactive element is at the bottom, which is out of view due to the length of the text. Verification Result dialog (id=dialog2):. When the dialog closes as a result of the Add action and the Address Added dialog replaces the Add Delivery Address dialog, the Add Delivery Address dialog passes a reference to the Add Delivery Address button to the Address Added dialog so that it can maintain the user's point of regard when it closes. When the dialog closes as a result of the Cancel action, the user's point of regard is maintained by returning focus to the Add Delivery Address button. 
The dialog does not need aria-describedby since there is no static text that describes it.Initial focus is set on the first input, which is the first focusable element.Add Delivery Address dialog (id=dialog1):.To make the content easier to read when displayed on small screens, the dialog fills 100% of the screen.Ĭompletely covering the background window also hides background movement that occurs on some mobile devices when scrolling content inside the dialog.įocus and accessible descriptions are set based on the content of each dialog. Nonetheless, making the first paragraph focusable and setting the initial focus on it is the most broadly accessible option. With some screen readers, this may have one negative but relatively insignificant side effect when the dialog opens - the first paragraph may be announced twice. The first paragraph is also contained inside the element that provides the dialog description, i.e., the element that is referenced by aria-describedby. In this dialog, the first paragraph has tabindex= -1. The dialog contains its label and a lot of content! If a dialog like this one has focus, the actual focus is difficult to comprehend. Screen readers read the label and content of focusable elements.
The dialog has a visual border, so creating a clear visual indicator of focus when the entire dialog has focus is not very feasible. The larger a focusable element is, the more difficult it is to visually identify the location of focus, especially for users with a narrow field of view. Please DO NOT make the element with role dialog focusable! Make a static element focusable, e.g., the dialog title or the first block of text. Place an interactive element at the top of the dialog, e.g., a button or link. There are several ways to resolve this issue: The keyboard focus always remains visible. The beginning of the text is visible so users do not have to scroll back to start reading. When the dialog opens, it is important that both: If the validation message is visible and the focus is on the help link, then the focus may not be visible. If focus is placed on the first interactive element when the dialog opens, the validation message may not be visible. The first interactive element, the help link, is at the bottom of the dialog. If it were a real application, it would provide a message telling whether the entered address is valid.įor demonstration purposes, this dialog has a lot of text.
0 kommentar(er)
