WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 3 months ago

#43169 reviewing defect (bug)

Media views: avoid to move focus programmatically when not strictly necessary

Reported by: afercia Owned by: joemcgill
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-screenshots has-patch dev-feedback
Focuses: ui, accessibility, javascript Cc:

Description

Ideally, focus should be managed programmatically only to "repair" the native tab order and avoid focus losses. For example, when opening a modal dialog focus needs to be moved to the modal and when closing it, focus must be moved back to the control that opened the modal.

In the media views, in many cases, moving focus is designed for a mouse-based interaction flow and, generally, it appears it was designed with a specific workflow in mind, that is: the workflow the developers felt was "right". In other words: based on assumptions.

While I understand the intent was good, this is very problematic for keyboard users. Let's make a couple examples:

https://cldup.com/SpSTMrgvdn.png

When adding an attachment to a post, for example selecting an image in the media grid, focus is moved to the URL field in the details sidebar. This is not an issue for mouse users: they can click another image at any time. Now, say a keyboard users is trying to add a gallery and needs to select multiple images: every time the user selects an image pressing the Spacebar, focus goes to the sidebar. Now the user is forced to tab many times, potentially hundreds of times depending on the number of images in the grid, to go to the grid again and select another image. Not to mention screen reader users will hardly understand why the context is changed and what the next step is.

In this case, focus should just stay in place on the selected image. It is far better to avoid an abrupt change of context rather than assuming that moving focus to the URL field is of any help for users.

One more example:

https://cldup.com/xmCQcKmGST.png

Over time, the media modal has been adapted and used also for other core features. In the screenshot above, that is what happens when editing an image attached to an Image widget in the widgets screen. Focus is moved to the URL field, if the image is linked (when it's not linked, there's no URL field displayed). Notice this happens only the first time the modal opens, not sure why.

Regardless, for keyboard and screen reader users big part of the content of the modal gets "skipped" and they land in the middle of some content without any context or meaningful information about what just happened.

I'd like to propose to remove any focus management from the media views, except for the cases where keeping focus within the modal is necessary. It is far better to keep the native tab order: users will find their way, once they learn how the interface is structured. Worth reminding assistive technologies users already have tools to jump to different part of the content, if the content is semantic and well structured.

I'd also like to quote what the React team states in their documentation dedicated to accessibility, they say it very well, far better than I could ever say:

https://reactjs.org/docs/accessibility.html#programmatically-managing-focus

Use it (Ed. focus management) to repair the keyboard focus flow when it is disturbed, not to try and anticipate how users want to use applications.

Attachments (1)

43169.diff (27.7 KB) - added by afercia 5 months ago.

Download all attachments as: .zip

Change History (7)

#1 @afercia
5 months ago

Partially related: #41612

@afercia
5 months ago

#2 @afercia
5 months ago

  • Keywords has-patch dev-feedback added

Typically, the cases where managing focus programmatically is necessary are:

  • when opening and closing the media modal
  • then the media modal view changes and its whole contant re-renders
  • when adding or deleting attachments

43169.diff is a first pass

  • keeps focus management in the cases above and in a few other cases that make sense
  • removes any other usage of focus()
  • makes the edit-attachment navigation buttons really disabled when there are no next or previous attachments
  • tries to clarify with inline comments all the usages of focus()

There are a couple issues to address yet, most notably when MEDIA_TRASH is set to true, when deleting attachments from the Media Library, the view is re-queried and reset. This makes difficult to restore focus in a proper place and would probably need an event that fires at the end of the view re-rendering or something similar. Any help very welcome.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 months ago

#4 @afercia
5 months ago

  • Milestone changed from Awaiting Review to 5.0

This ticket was mentioned in Slack in #core-media by afercia. View the logs.


3 months ago

#6 @joemcgill
3 months ago

  • Owner set to joemcgill
  • Status changed from new to reviewing
Note: See TracTickets for help on using tickets.