#37589 closed defect (bug) (fixed)
Safari, VoiceOver and the CSS property user-select
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Customize | Keywords: | has-screenshots has-patch |
Focuses: | ui, accessibility | Cc: |
Description
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:
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 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)
Change History (11)
This ticket was mentioned in Slack in #core-customize by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-customize by afercia. View the logs.
8 years ago
#7
@
8 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
@
8 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
@
8 years ago
- Owner set to afercia
- Resolution set to fixed
- Status changed from new to closed
In 38642:
37589.diff takes a minimal approach and just resets to
auto
the inheriteduser-select
value of the Customizer available menu items accordions. By the way, I'd suggest to consider to review the usage ofuser-select: none
globally and use::selection
instead.