Dialog & Popover: Dummy element for default initial focus

[rolfsmeds]

Describe your motivation

When a Dialog or Popover (with autofocus) is opened, keyboard focus goes automatically to the overlay element itself. There are two problems with this:

1. Some screen readers announce the entire contents of the overlay ([dialog] NVDA announces full contents of Dialog when opened #5709)
2. There is no visual focus indicator (dialog / confirm-dialog / crud: unnecessary/inappropriate invisible focus stop #140)

We need a solution that

• Ensures screen reader users discover all content in the dialog
• Ensures that screen readers only announce the actual title, and, if provided, the element associated with aria-describedby, not the entire contents of the overlay, when opened
• Ensures that sighted keyboard users can always see where focus is

This means that

• Initial focus needs to be placed on an element other than the overlay itself
• Initial focus needs to be visually indicated, wherever it's placed
• The initially focused element must precede all other content in the overlay

Additionally, the element that receives initial focus does not need to be part of the normal tab order / manually focusable by keyboard users, i.e. it can have tabindex="-1".

Describe the solution you'd like

A "dummy" element with tabindex="-1" inside the overlay (before any other content).

Need to check if the accessible name of the dialog is automatically announced when focus is placed on this dummy – if not, the overlay's accessible name could be applied to the dummy using aria-labelledby.

It would still make sense to visually indicate focus on the overlay itself – this could be achieved by positioning the dummy to "cover" the overlay surface (simliarly to the focus-button in vaadin-dashboard-widget) or by applying a focus ring to the overlay itself when the dummy element has focus (e.g. using :has())

Other options considered

The typically cited solution for overlay focus is to set focus on the first focusable element inside the overlay. This only works if the first focusable element is also the first element relevant to the user. If the first focusable element is preceded by non-focusable content, such as a text element, it will almost certainly be missed by screen reader users. In some cases it might be possible to associate that text with the overlay's aria-describedby, but that is also not a universally applicable solution.

Another common solution is to set focus on the overlay's title, but this has two problems:

• While the Dialog has a built-in title element, not all dialogs use it (e.g. if they need richer header content than just a heading), and Popover does not have one at all. Overlays without a a built-in title would need to fall back to some more generic solution such as focusing the first focusable element.
• While an appropriate visual focus indicator could easily be implemented based on the Dialog's built-in title element, this would not be possible with a generic first-focusable-element solution, as there would not be a reliable way to determine whether a focus ring should be rendered on the overlay itself.

These enhancements would fix
#140
#5709

[knoobie]

Suggestion: Instead of adding again (thinking v8) a initial element to focus ("tab stop") inside the dialog.. wouldn't it be possible that the dialog automatically focuses the first added component inside the dialog that is focusable? For example all my dialogs already have <hx tabindex="-1">Heading</hx> which I automatically focus onAttach of the dialog.

[rolfsmeds]

The problem is that most dialogs are not like that, and we can't really make any assumptions about their contents. Setting initial focus to the first focusable element would in many cases cause screen readers to completely skip headings and body text in the dialog, and go straight to e.g. the first input field or button. You will still be able to override that default to your own heading elements or whatever makes sense, but we want to provide a default that is most likely to result in a reasonable screen reader UX in dialogs whose implementer is not familiar with the matter.

[knoobie]

Totally valid concern! 👍 I'm closely following the development to make sure I can override the default :)