[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