Page MenuHomePhabricator

VE paste surface read by screenreader
Closed, ResolvedPublic

Description

When I use Safari/VoiceOver, copy something in DT visual mode and then try to navigate out of the editable surface, the next element in the navigation suequence is another editable, which seems to contain a copy of my last selected VE text. This should probably be hidden from screenreaders using aria-hidden.

<div class="ve-ce-surface-paste noime" tabindex="-1" contenteditable="true"><p><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: -webkit-standard; font-size: medium;">om</span></p></div>

Event Timeline

I'm happy to add that if you think it helps, but how is the focus ending up on that element given that it has tabindex="-1"? Maybe it's some problem with our own focus handling.

There is a difference between tabbable (keyboard navigation) and focusable (able to receive focus/interact with it). You can MAKE a non-interactive element tabbable AND focusable by setting tabindex=0, but you cannot make an interactive element unfocusable by setting tabindex=-1, that only removes it from the tab order, but the accessibility cursor is independent of the tab order. The focus 'follows' the tab order (like a dog following its owner), but it is not the same thing.

This might be interpreted slightly more strict here because it is in a form.

https://html.spec.whatwg.org/multipage/interaction.html#the-tabindex-attribute

−1 (or other negative integer values)
Causes the element to be focusable, and indicates that the author would prefer the element to be click focusable but not sequentially focusable.

This is also why jQuery UI has :focusable and :tabbable selectors

Change 698021 had a related patch set uploaded (by Esanders; author: Esanders):

[VisualEditor/VisualEditor@master] Set aria-hidden on pasteTarget

https://gerrit.wikimedia.org/r/698021

Change 698021 merged by jenkins-bot:

[VisualEditor/VisualEditor@master] Set aria-hidden on pasteTarget

https://gerrit.wikimedia.org/r/698021

matmarex assigned this task to Esanders.

Hopefully that fixes it, @TheDJ we'd appreciate if you could confirm.

There is a difference between tabbable (keyboard navigation) and focusable (able to receive focus/interact with it). You can MAKE a non-interactive element tabbable AND focusable by setting tabindex=0, but you cannot make an interactive element unfocusable by setting tabindex=-1, that only removes it from the tab order, but the accessibility cursor is independent of the tab order. The focus 'follows' the tab order (like a dog following its owner), but it is not the same thing.

This might be interpreted slightly more strict here because it is in a form.

I'm aware of the difference, I'm just surprised that focus can apparently end up in a non-tabbable, non-clickable, invisible element, without us making that happen in our code.

Change 698619 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (3891890c2)

https://gerrit.wikimedia.org/r/698619

Change 698619 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (3891890c2)

https://gerrit.wikimedia.org/r/698619

@matmarex I can no longer reproduce the issue on https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Main_Page so looks like it might be fixed.