#33902 closed defect (bug) (fixed)
Accessible Tags auto-complete
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | 4.3 |
Component: | Administration | Keywords: | has-patch needs-testing |
Focuses: | ui, accessibility, javascript | Cc: |
Description
In a couple of places in the admin, jquery.suggest
displays a drop-down with suggested tags as you type. This little script shows its age but it still works pretty good. When used with a keyboard though, there are a some usability issues (see also #32580) and, most of all, the suggestions list is not accessible. There's room for improvements :)
This script has been patched for WordPress in the past, I guess it's not officially maintained anymore and it's possible to further patch it for our needs. Things to take care of:
- when there are saved tags (see the Quick Edit form), tabbing away from the textarea will reveal the suggestions list (see screenshot 1)
- related to above, the interval to hide suggestions on blur is always 200 ms but the delay to display the suggestions is configurable via settings, we should clear the latter on blur
- the script assumes the initial input field value length is 0 (it assumes to find an empty field) but this may not be true when there are already saved tags (i.e. in the Quick Edit form)
- in the Quick Edit form, pressing Escape when in the textarea should close the suggest tooltip but closes the whole Quick Edit
- finally, I'd propose to use the proper ARIA roles and properties to make it a fully accessible ARIA widget, the most known examples are Twitter and Gmail search suggestions
Suggestions shown when tabbing away:
In the two screenshots below, see how the light yellow background to highlight the "focused" suggestion is barely noticeable. Also, screen readers can't read out the suggestions list content (this actually is the same thing that happens in the current implementation of Select2, version 4).
The current suggestions list in the Tags postbox:
The current suggestions list in the Quick Edit form:
Attachments (3)
Change History (50)
#3
follow-up:
↓ 4
@
9 years ago
Just to throw it out there: how much of this would automatically be addressed by moving to another library?
#4
in reply to:
↑ 3
@
9 years ago
Replying to boonebgorges:
Just to throw it out there: how much of this would automatically be addressed by moving to another library?
Depends on the library. This is something I would also like something like Select2 to handle (see #31696), but based on the accessibility team's testing of the current state of Select2, the answer is that it could be worse.
#5
@
9 years ago
It might be possible to get Select2 in at some point, but it's not there yet. For now, it would be worthwhile to have this work better, even if it's not perfect, then throw some resources at Select2 to try and prepare it for a future release.
If you have a specific library you think it would be worth looking at, we'll do that. We're not wedded to Select2.
#6
follow-up:
↓ 7
@
9 years ago
If you have a specific library you think it would be worth looking at, we'll do that.
I guess I was thinking mainly of jQueryUI autocomplete. We already package it, and we already use it in a few places, as when adding an existing user to a site. I don't know how much work it would be to migrate over (I'm guessing a moderate amount), and I don't know how much stuff in the wild would be broken by moving away from select.js (I'm guessing fairly little, since it's not extensible anyway).
#7
in reply to:
↑ 6
;
follow-up:
↓ 8
@
9 years ago
Replying to boonebgorges:
I guess I was thinking mainly of jQueryUI autocomplete.
@boonebgorges (hi) have a look at this. To save time, just read the ticket title and the last comments :)
#8
in reply to:
↑ 7
@
9 years ago
Replying to afercia:
Replying to boonebgorges:
I guess I was thinking mainly of jQueryUI autocomplete.
@boonebgorges (hi) have a look at this. To save time, just read the ticket title and the last comments :)
Fair enough :) Using Select2 for autocomplete in text fields sounds pretty weird https://www.drupal.org/node/2346973#comment-9550071, but I guess I can see the benefits in using a single library for all similar interfaces. In any case, I have no particular allegiance to jQuery UI Autocomplete, or any other tool in particular; just a general preference for sinking dev time into the integration of properly maintained libraries rather than maintaining our own, all things being equal. But it sounds like, in this case, all things are not equal - so carry on :)
This ticket was mentioned in Slack in #core by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-editor by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #design by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#17
@
9 years ago
- Keywords needs-refresh added
- Milestone changed from Awaiting Review to 4.6
- Owner set to azaozz
- Status changed from new to assigned
Discussed a bit in today's a11y bug-scrub and decided together with @azaozz to try this for 4.6. After all the work done for the Editor inline link toolbar autocomplete, it would be great to use the same jQuery UI implementation also for the Tags.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#19
@
9 years ago
- Keywords early added
- Milestone changed from 4.6 to Future Release
Not enough time to handle this in the 4.6 release cycle, punting to future release early.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by stevenkword. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-editor by afercia. View the logs.
8 years ago
#25
@
8 years ago
- Keywords needs-patch added; has-patch needs-refresh removed
Discussed a bit this ticket with @azaozz and the plan is to try to implement the same jQuery powered autocomplete currently used for the inline link toolbar in the editor. It's already tested, it's accessible, not to mention the added value given by using the same component without having to reinvent the wheel. So the current patch should be ignored and a new patch with the new approach be prepared, hopefully for 4.7 :)
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#27
@
8 years ago
- Keywords has-patch needs-testing added; needs-patch removed
In 33902.3.patch:
- Use UI Autocomplete for suggesting tags in the metabox(es) on the Edit Post screen and in quick and bulk edit.
- Use the same Autocomplete settings like the editor link toolbar.
- Fix suggesting tags for custom taxonomies for bulk edit.
The patch adds tags-suggest.js and makes it a dependency for inline-edit-post.js and tags-box.js. Also adds data-wp-taxonimy
attribute on the tag input elements to better support custom taxonomies in the UI.
@afercia could you check if I didn't miss anything a11y related please.
#28
@
8 years ago
@azaozz it's great to see this landing in core, thanks :) All the aria roles/attributes look OK to me after a first check. Few things noticed so far:
Safari 10 + VoiceOver: not sure why sometimes the wrong option gets announced, see screenshot below:
This seems to happen also in the editor inline link toolbar now, but I don't remember it happening last time I tested it. Not sure if something has changed or Safari 10 introduced a bug. I guess would need some investigation.
In the quick edit form, pressing Enter to choose an highlighted tag closes the quick edit form too.
speak( window.uiAutocompleteL10n.itemSelected );
needs the window.wp
part or be a variable as in the TinyMCE plugin
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by afercia. View the logs.
8 years ago
#32
@
8 years ago
I'd propose to change colors of the highlighted options, for accessibility the color contrast ratio should be at least 4.5:1. White text on a #0073aa
background (the default WP blue for links) could be an option.
Note: the changes proposed in #27555 should be coordinated with this ticket. Maybe better to merge this first and then refresh #27555.
#33
follow-ups:
↓ 34
↓ 36
@
8 years ago
Re: Safari + VoiceOver, I can reproduce the weird behaviour even on other implementations that perfectly worked while developing a similar feature for the editor link toolbar, see https://webkit.org/blog-files/aria1.0/combobox_with_live_region_status.html (demo from Example 2 on https://webkit.org/blog/3302/aria-and-accessibility-inspector/). Not sure there's much to do here.
The options are correctly announced using Firefox+NVDA and IE11+JAWS.
One improvement I'd consider to add is preventing the default action when pressing Tab. The interaction here is different from the link toolbar autocomplete, where just one option can be selected at a time. About tags instead, it is possible to add multiple tags so it would be nice to make a Tab press select the highlighted option and keep the cursor inside the input field. As far as I see, this would be as simple as adding event.preventDefault();
when checking for the key 9
.
#34
in reply to:
↑ 33
@
8 years ago
Replying to afercia:
Right. Thinking we should add this so it is easier to test and improve/fix. When testing it would be good to have a custom taxonomy that is shown in the UI. To do that need to paste this temporarily in a plugin somewhere:
add_action( 'init', '_my_add_custom_taxonomy', 1 ); function _my_add_custom_taxonomy() { register_taxonomy( 'my_custom_tags', 'post', array( 'hierarchical' => false, 'labels' => array( 'name' => __( 'Custom tags' ), 'singular_name' => __( 'Custom tags' ), ), 'query_var' => 'tag', 'rewrite' => false, 'public' => true, 'show_ui' => true, 'show_admin_column' => true, 'capabilities' => array( 'manage_terms' => 'manage_post_tags', 'edit_terms' => 'edit_post_tags', 'delete_terms' => 'delete_post_tags', 'assign_terms' => 'assign_post_tags', ), ) ); }
#36
in reply to:
↑ 33
@
8 years ago
Replying to afercia:
Added all from the comments above including preventDefault()
on Enter and Tab. Left the CSS changes / highlight color for #27555.
Feel free to tweak/fix everything that needs it, or let me know if anything is not working properly (anything else than Safari + VoiceOver announcing the wrong element as selected...).
This would also need more testing in various browsers.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#38
@
8 years ago
Thanks @azaozz ! Just came into my mind: needs to check what happens in Press This :)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#41
@
8 years ago
I've tested again with Safari + VoiceOver on macOS Sierra and couldn't find a way to solve the issue related to the wrong option being announced. To me, this seems a Safari+VoiceOver regression, since it is now happening also on the wplink inline toolbar autocomplete that was extensively tested when implemented and was perfectly working. See i the screenshot below:
It could also depend on the macOS version. The only example that works for me right now is the Twitter autocomplete, that uses a very similar implementation but couldn't figure out why the Twitter one works.
First pass. There are still some things to improve for keyboard usability but the accessibility part should be on the right track. See in the screenshot below how the suggestions list content gets read out now, announcing it's "expanded", the number of suggestions found, saying that it's a list and saying "n of n" for each item when focused. The styling part is inspired by the styles that Press This applies on this list, open to any thoughts and suggestions.
Side note: still investigating if a "combobox" role is appropriate for the input field in this case, probably not.