The 10th and final webinar in our Accessibility Basics Webinar Series covered best practices for accessible dialogs. In this post the presenter – Accessibility Training Specialist Erica Zelmanowicz – has provided answers to the questions we received during the webinar.
The webinar slides, transcript, and recorded presentation can be accessed at https://dev-level-access.pantheonsite.io/resources/overview/.
Dialogs Webinar Q&A
If you use role=dialog, do you still need to add offscreen text to demarcate the boundary of dialog?
//EZ: role=”dialog” will help identify the grouping of the content as a dialog, however, you will need to also include a properly labeled dialog as well as manage keyboard focus. So role=”dialog” is not sufficient to create an accessible dialog. That being said, if you provide all of that information, you do not need to add off-screen text to identify the boundaries of the dialog.
Should we load the focus on a modal window by default or the close button of the modal?
//EZ: This is somewhat of a business decision for your organization, however, if you place focus at the very top, the user can navigate through the dialog manually to determine what is in place and the location of the elements on the screen.
Should NVDA announce the modal contents on loading of dialog, or the content should be announced as user presses down arrow key?
//EZ: If your dialog is properly labeled, the screen reader will read the label you assigned to that dialog. Then the user will have control to navigate through the dialog and will hear the contents of the dialog.
How do you set focus on title, without actually showing the focus indicator?
Where is the beginning-end requirement documented?
//EZ: This falls under Section 508 1194.22 – A text equivalent for every non-text element shall be provided (e.g. via “alt”, “longdesc”, or in element content): https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards
Regarding demarcation of the dialog, would trapping focus in the dialog and hiding the background content be a sufficient technique?
//EZ: Yes, this should be fine – as long as the user’s focus remains in the dialog, they can understand the boundaries of the dialog.
Are you saying that a dialog receives focus but only on the first element (not control) and then the user chooses if, when, or whether to read the remaining contents?
//EZ: When you set focus to the dialog as a whole, you are not actually placing it in the tab order, but providing a way for the user to hear the title of the dialog and then manually navigate through the dialog to locate controls or text.
How do you inform SR user to use arrow keys?
//EZ: There are design patterns and keyboard shortcuts that screen reader users are aware of – when navigating in a dialog, this is a common navigation technique. If they are in a calendar where the arrow keys are used to navigate between dates, you could provide some documentation on how a user could navigate through the table, but again, some of these are standard design patterns that are commonly used by screen reader users.
How do you provide a textual indication of unavailable dates within a calendar
//EZ: You can use off-screen text to identify unavailable dates.
Should screen readers be able to access read-only fields within a dialog
//EZ: Yes – anything that is accessible via the mouse or visually should also be accessible via a screen reader. When a user navigates into the field, it should be identifiable as read-only.
Are you only addressing modal dialogs in the webinar? What about non-modal dialogs?
//EZ: These concepts apply to both modal and non-modal dialogs. The one that is specific mainly to non-modal dialogs is ensuring that the user understands the boundaries of the dialog by either using a region or off-screen text. In a non-modal dialog, since the user does have the ability to navigate outside of the dialog, this is important for screen reader users to know that they have navigated outside of that dialog