[wp-trac] [WordPress Trac] #47136: Image Editor: Reading and focus order do not match visual order

WordPress Trac noreply at wordpress.org
Wed Jun 24 16:21:30 UTC 2020


#47136: Image Editor: Reading and focus order do not match visual order
-------------------------------------------------+-------------------------
 Reporter:  anevins                              |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  5.5
Component:  Media                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots wpcampus-report      |     Focuses:  ui,
  has-patch                                      |  accessibility
-------------------------------------------------+-------------------------

Comment (by afercia):

 @sabernhardt thanks for your thorough testing. I tested it with Windows
 screen readers as well and you're right. Seems setting focus on the
 `imgLoaded` function wasn't a good idea, my fault.

 That's not so reliable as it depends on browsers implementation, whether
 the image is cached or not, and also whether the browser's dev tools are
 open, which makes testing a bit misleading.

 Regarding:
 > but it seems the focus is going to something immediately before the Crop
 button

 Yep, I guess that's the effect of the so called "sequential focus
 navigation starting point". For Chrome, see
 https://bugs.chromium.org/p/chromium/issues/detail?id=454172. Firefox
 implemented it way before Chrome. Basically, when a portion of the DOM
 that contained focus is removed, modern browsers try to make an educated
 guess on the most reasonable place where to start the tab sequence from.

 In our case, especially when screen readers are running, seems that the
 element to focus it not there yet, or at least the browser didn't update
 the accessibility tree yet. Thus, the "sequential focus navigation
 starting point" kicks in. Note that IE didn't ever implement this feature,
 which contributes to the different testing results.

 Ideally, we should try to move focus on a more reliable callback or event.
 One that runs when the Image editor is fully rendered. Alternatively, I
 think your approach with `setTimeout()` is sae enough as the worst thing
 can happen is focus isn't moved (no potential JS errors).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47136#comment:48>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list