A really common pattern for modal dialogs is that when the dialog is opened, focus is taken to the dialog container.
This is despite the fact that the W3C Web Accessibility Initiative modal dialog tutorial (and pretty much any modal dialog example/tutorial I've ever seen) tells people to take focus to something inside the dialog.
Focusing the dialog container can cause accessibility problems:
- in the NVDA screen reader, at least, it causes the dialog role to not be announced when opened
- in NVDA, at least, focusing a container causes a screen reader to read all of the content in the container until the user manually stops it, not a good experience.
- Focusing the dialog container rather than the most sensible interactive element in the dialog delays the user's ability to use the dialog content
Focusing the dialog container causes NVDA to not announce a dialog
In the NVDA screen reader, when a dialog container is focused, whether it's a <dialog> element or a div with the dialog role, it is not announced as a dialog. However, if focus is taken to something inside the dialog, the dialog is announced.
This is apparently a known NVDA issue. I don't know if any other SRs exhibit this behaviour. Testing with Mac VoiceOver/Chrome and Android TalkBack/Brave browser resulted in the dialog role being announced, as expected. However, since NVDA is currently the second most-used screen reader, it's important to support it, even if this isn't expected behaviour.
In addition, the WAI modal dialog tutorial indicates that focus should be taken to an element inside a dialog on open:
When a dialog opens, focus moves to an element contained in the dialog. Generally, focus is initially set on the first focusable element. However, the most appropriate focus placement will depend on the nature and size of the content.
NVDA reads all content inside a focused container
By default, NVDA will read all of the content inside a container when it is focused, until the user stops it. This isn't exactly desirable behaviour, as browsing should be under user control. This is apparently due to an "Automatic Say All on page load" setting, which is turned on by default. This setting is also the reason the dialog role isn't announced.
Focusing the dialog delays user interaction with dialog content
When the dialog container is focused rather than an interactive element in the dialog, user interaction with the dialog is delayed, as they must navigate forward to find and interact with its contents.
When a modal dialog is opened, focus should be set on the most sensible interactive element it contains, so users can immediately begin interacting with the content. What that element is depends on the dialog content and purpose. Often, a "close" button may be the only interactive element in a dialog. As long as the dialog is properly labelled (a separate topic) and aria-describedby is used to programmatically associate any descriptive text with it, focusing the close button works just fine.
The dialog that inspired this investigation is a modal whose only content is a search form and a close button. Given that the purpose of the dialog is to perform a search, focus should go to the search input when it is opened. That way, users can immediately type their desired search terms and perform a search without first having to navigate from the dialog container to the form.