dialog / confirm-dialog / crud: unnecessary/inappropriate invisible focus stop

[TetraLogicalHelpdesk]

WCAG Level

Level A

Priority

Medium

Pages/screens/components affected

• Dialog
• Confirm Dialog
• CRUD

Description

For people who navigate using a keyboard or keyboard-like device (such as a switch control or a joystick) the focus order of interactive controls in a document should be logical and intuitive.

In components that generate a modal dialog (such as vaadin-dialog, vaadin-confirm-dialog and the variant of CRUD that uses a dialog), the dialog itself is keyboard-focusable when open. Cycling focus through the dialog, focus appears to momentarily "disappear" when the overlay of the dialog itself receives focus.

User impact

If the focus order is not logical, sighted keyboard users are likely to be confused and irritated when navigating through a site, particularly if the focus appears to "jump" in an illogical manner to different, seemingly unconnected parts of the screen. This issue will be even more problematic of users of assistive technologies, who may not have the benefit of being able to perceive the overall layout/structure of the page to realise that that the illogical focus order has potentially moved them to a completely separate part of the current page.

In this case, the issue is minimal, but it is still confusing for keyboard users, when cycling through an open dialog using Tab/Shift+Tab, to find their focus "disappear". It introduces an unnecessary and redundant focus stop for keyboard users.

Required solution

Make sure that the dialog itself is not keyboard focusable - only focusable elements inside the dialog should receive keyboard focus.

This solution must be applied to all instances of the issue identified within the test sample, then applied to all other instances of the same issue identified throughout the rest of the website.

Implementation guidance

Currently, the dialog overlay itself uses tabindex="0" - presumably to enable it to be programmatically focused.

<vaadin-dialog-overlay ...>
  # Shadow root
  ...
  <div part="overlay" id="overlay" tabindex="0">
    ...
  </div>
</vaadin-dialog-overlay>

Instead, replace this with tabindex="-1" - this still allows the dialog to be focused using the focus() method, but it won't include the dialog in the regular keyboard focus cycle.

<vaadin-dialog-overlay ...>
  # Shadow root
  ...
  <div part="overlay" id="overlay" tabindex="-1">
    ...
  </div>
</vaadin-dialog-overlay>

Test procedure(s)

Use these steps to confirm that the solution has been correctly applied:

1. Use Tab/Shift+Tab to navigate through the page.
2. Verify that the order in which elements receive focus is logical and consistent.
3. Open the dialog.
4. Using Tab/Shift+Tab, cycle through all focusable elements in the dialog.
5. Verify that focus does not also land on the dialog container itself (as the dialog itself has no visible focus indication, this would visually manifest itself as the focus "disappearing" after the last focusable element was tabbed away from, and before the first focusable element in the dialog receives focus).

Definition of done

Complete all of these tasks before closing this issue or indicating it is ready for retest:

• All issues identified within the test sample have been resolved.
• The rest of the components, their variants, and the documentation website have been tested for the same issue.
• All issues identified throughout the rest of the components/website have been resolved or filed as new issues.

Related standards

• WCAG 2.1 Success Criterion 2.4.3 Focus Order (Level A)
• WCAG 2.1 Success Criterion 2.4.7 Focus Visible (Level A)

More information

• W3C - Placing the interactive elements in an order that follows sequences and relationships within the content

Test data

Test date: March 2021 Website: vaadin.com/components, vaadin.com/docs-beta

[web-padawan]

See also https://github.com/vaadin/web-components/issues/164#issuecomment-810820745

[kPlock]

Also brocken with tabindex="0" ;-(

If a Component is a RichTextEditor (vaadin) inside a Dialog you are not able to click inside it for writing and with turn focus by TAB is not working. P.S. with TAB / SHIFT (back focus) you can get...

[rolfsmeds]

@kPlock that sounds like a completely unrelated issue. Could you please make a separate bug ticket about that, and provide a reproducible example?

[TatuLund]

@kPlock update to 24.2.6, see https://github.com/vaadin/flow-components/issues/5829