Problem/Motivation
When a keyboard user operates a "place block" button on the block layout page (admin/structure/block) a modal dialog presents the available blocks, but the keyboard focus does not move to the dialog content. Focus remains on the place-block button.
This is a different behaviour to the dialogs in Views UI, which move focus to the first focusable item in the dialog's main content.
A demo recording of this problem is on YouTube, from the Drupal Usability Meeting - 15 May 2018, starting around 31m.
Affected dialogs:
- place block dialog on admin/structure/block
- MediaLibraryWidget (add media button opens a dialog)
Some additional consequences:
- Pressing ESC is expected to dismiss modal dialogs. However this doesn't work until focus has entered the dialog. So a sighted keyboard user sees a dialog, but it can't be dismissed by the normal behaviour.
- Screen reader users may not be immediately aware that the dialog has opened - it would be announced when entering the dialogue (i.e. when focus moves to a child element inside the dialog). Focus remains on a place-block button, which apparently did nothing.
The problem is somewhat mitigated by the fact that pressing tab will move focus to the "add custom block" link, which is the first visible focusable control in the dialog content. Screen readers announce the dialog at this point, and the ESC behaviour comes into play.
The current working draft of the W3C WAI-ARIA Authoring Practices describes the expected behaviour:
When a modal dialog opens focus goes to the first focusable item in the dialog.
Proposed resolution
When the dialog is opened, move focus programatically to the first control in the dialog content (the add custom block link).
Remaining tasks
Fix it - are we programatically focussing the wrong element?
User interface changes
- No visible inteface changes.
- Corrects the keyboard behaviour of a modal dialog, to match the behaviour of dialogs elsewhere in Drupal's admin interface.
API changes
None expected.
Data model changes
None expected.