Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Focus loss when switching to draft #51901

Closed
afercia opened this issue Jun 26, 2023 · 0 comments · Fixed by #54722
Closed

Focus loss when switching to draft #51901

afercia opened this issue Jun 26, 2023 · 0 comments · Fixed by #54722
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Edit Post /packages/edit-post [Package] Editor /packages/editor [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Jun 26, 2023

Description

When switching a Published or Scheduled post to Draft:

  • The Switch to Draft button gets a disabled attribute while saving.
  • This triggers an immediate focus loss, as the element that had focus is now not focusable. See Don't use disabled on focusable UI controls e.g. "Reset" buttons #15524
  • A confirm dialog opens, focus is moved to the dialog.
  • WHen pressing OK to save as a Draft, the dialog opens and the Switch to Draft is removed from the DOM.
  • As such, the dialog can't restore focus on the control that opened it.
  • A focus loss occurs.
  • At this point, when pressing the Tab key, the tab sequence starts from scratch from the document root.

Animated GIF to illustrate:

switch to draft focus loss

Worth noting the focus loss occurs also in WordPress 6.2, However, the Switch to Draft button was placed in the editor top bar. While the focus loss still occurs, I'd say it wa less serious because focus landed not that far from where it was.

Instead, with the new placement of the Switch to Draft button in the settings panel, users are now forced to navigate almost the entire editor UI to go back where they were.

The expected behavior is that focus is returned to the UI control that opened the modal dialog. As such, the 'Switch to Draft' button should not be removed from the DOM. Ideally, it shoul dstay in the DOM, be still focusable, use an aria-disabled attribute and 'noop'. See: ARIA Authoring Practices: Focusability of disabled controls.

Step-by-step reproduction instructions

  • Edit a Published or Scheduled post.
  • Use the keyboard and navigate with the Tab key to the 'Switch to Draft' button in the Settings panel.
  • Press Enter: a confirm dialog opens.
  • Tab to the OK button and press Enter.
  • The dialog closes.
  • Observe the 'Switch to Draft' button is removed from the DOM.
  • Press the Tab key.
  • Observe the tab sequence starts from scratch from the Site icon button at the beginning of the document.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@afercia afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Editor /packages/editor [Package] Edit Post /packages/edit-post [a11y] Keyboard & Focus labels Jun 26, 2023
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Edit Post /packages/edit-post [Package] Editor /packages/editor [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants