[wp-trac] [WordPress Trac] #43169: Media views: avoid to move focus programmatically when not strictly necessary

WordPress Trac noreply at wordpress.org
Sat Jan 27 19:13:51 UTC 2018


#43169: Media views: avoid to move focus programmatically when not strictly
necessary
-------------------------------------------+-----------------------------
 Reporter:  afercia                        |      Owner:
     Type:  defect (bug)                   |     Status:  new
 Priority:  normal                         |  Milestone:  Awaiting Review
Component:  Media                          |    Version:
 Severity:  normal                         |   Keywords:  has-screenshots
  Focuses:  ui, accessibility, javascript  |
-------------------------------------------+-----------------------------
 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:

 [[Image(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:

 [[Image(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'''.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43169>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list