[wp-trac] [WordPress Trac] #37589: Safari, VoiceOver and the CSS property user-select

[WordPress Trac]

#37589: Safari, VoiceOver and the CSS property user-select
-------------------------------+-----------------------------------------
 Reporter:  afercia            |      Owner:
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Future Release
Component:  Customize          |    Version:
 Severity:  normal             |   Keywords:  has-screenshots needs-patch
  Focuses:  ui, accessibility  |
-------------------------------+-----------------------------------------
 This seems specific to Safari+VoiceOver and is yet another case where CSS
 can seriously affect screen readers behaviour. I can reproduce it
 consistently using Safari+VoiceOver on OS X El Capitan:
 - go in the Customizer > Menus > any menu
 - click the "Add Items" button
 - focus is programmatically moved to the "Search menu items..." field
 - press Tab to navigate forward to the first accordion toggle using the
 keyboard
 - the toggle doesn't receive focus, VoiceOver starts reading out the whole
 container

 There's no way to move focus to the toggles when tabbing forward. Instead,
 using the arrow keys (Control-Option-Right arrow) works. Below, a couple
 screenshots to try to illustrate the issue:

 [[Image(https://cldup.com/ekHxUShYfY.png)]]

 [[Image(https://cldup.com/56YvIxGQin.png)]]

 TL;DR

 It took me a while to figure out what was going on here. Tried everything,
 markup, aria attributes, checked the JS part, and eventually tried
 removing some CSS properties. It turned out to be the `user-select: none`
 CSS property used on the accordion titles. Don't ask me why :)

 The only reference I could find is this (maybe related) webkit bug that
 seems to be solved in Chrome but maybe not in Safari:
 > AX: VoiceOver cannot use AXTextMarker calls when user-select:none
 > https://bugs.webkit.org/show_bug.cgi?id=57685
 Whether or not this webkit bug is really the culprit, it does confirm that
 non-standard properties like `user-select: none` can have undesired
 effects.

 As far as I can tell `user-select: none` was first introduced in [9689]
 and then extended to other accordions/menus. While it makes perfectly
 sense to use it for draggable/sortable elements, I'm not completely sure
 that's the case for menus. Maybe, this would be a good opportunity to
 review the `user-select: none` usage across the admin.

 Also, worth noting the implementation differs across browsers. For
 example, Firefox doesn't allow any text matching `user-select: none` to be
 copied while Webkit still allows the text to be copied if the selection
 starts on elements around it. Easy to verify: just go in any admin page
 and press `Cmd/Ctrl + A` to select all. Then copy and paste the selection
 in some editor, compare the results using Chrome and Firefox. Other
 inconsistencies are better described in a [https://www.w3.org/TR/2015/WD-
 css-ui-4-20150922/#valdef-user-select-none note on the CSS4 UI Working
 Draft spec].

 So, depending on the browser used, users won't be able to copy some text.
 Why they shouldn't be allowed to do that? If the intent is to don't show
 the selection "highlight", today `::selection` (`::-moz-selection` needs
 to be used separately) offers a better and standard way to style it and
 just setting a transparent background should work.

 At the very least, I'd propose to reset `user-select` to `auto` for these
 Customizer accordions. Quickly tested, it does solve the issue, see
 screenshot below:

 [[Image(https://cldup.com/5pSZMyGfUM.png)]]

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