Make WordPress Core

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#37589 closed defect (bug) (fixed)

Safari, VoiceOver and the CSS property user-select

Reported by: afercia's profile afercia Owned by: afercia's profile afercia
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Customize Keywords: has-screenshots has-patch
Focuses: ui, accessibility Cc:


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:


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

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 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:

Attachments (1)

37589.diff (619 bytes) - added by afercia 8 years ago.

Download all attachments as: .zip

Change History (11)

8 years ago

#1 @afercia
8 years ago

  • Keywords has-patch added; needs-patch removed

37589.diff takes a minimal approach and just resets to auto the inherited user-select value of the Customizer available menu items accordions. By the way, I'd suggest to consider to review the usage of user-select: none globally and use ::selection instead.

#2 @afercia
8 years ago

  • Milestone changed from Future Release to 4.7

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.

8 years ago

#4 @afercia
8 years ago

Noting sometimes user-select: none; is used in places where apparently there's no reason to use it, for example the "Add items" and "Reorder" buttons (same for the widgets "Reorder" and "Add a widget"):

This ticket was mentioned in Slack in #core by afercia. View the logs.

7 years ago

This ticket was mentioned in Slack in #core-customize by afercia. View the logs.

7 years ago

#7 @celloexpressions
7 years ago

I think we should be fine to remove user-select: none;; I don't imagine that it's particularly necessary in general. It's too bad that that old commit doesn't reference a ticket; I'm guessing that @azaozz doesn't remember whether there were any reasons besides the obvious not needing to select those? I could see more of an issue for sortable elements but shouldn't be needed for accordions.

#8 @afercia
7 years ago

Seems ::selection is not supported in iOS Safari 😞 so better to fix this specific issue in the Customizer and postpone the global replacement of user-select: none.

#9 @afercia
7 years ago

  • Owner set to afercia
  • Resolution set to fixed
  • Status changed from new to closed

In 38642:

Accessibility: Fix the Customizer available menu items toggles focus for Safari and VoiceOver.

In rare circumstances, for example buttons with icons and no visible text,
user-select: none; may trigger a bug that happens only when using Safari and
VoiceOver and doesn't allow focusable elements to receive focus correctly.
Worth reminding user-select: none; is a non-standard property and should be
used with care especially now that ::selection is almost universally supported.

Fixes #37589.

This ticket was mentioned in Slack in #core-editor by afercia. View the logs.

7 years ago

Note: See TracTickets for help on using tickets.