WordPress.org

Make WordPress Core

Opened 21 months ago

Closed 7 months ago

Last modified 5 weeks ago

#33902 closed defect (bug) (fixed)

Accessible Tags auto-complete

Reported by: afercia Owned by: azaozz
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:

https://cldup.com/v4kCaYg2qN.png

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:

https://cldup.com/3zXeFNKZHw.png

The current suggestions list in the Quick Edit form:

https://cldup.com/YsZ-SXACY7.png

Attachments (3)

33902.patch (8.4 KB) - added by afercia 21 months ago.
33902.2.patch (7.9 KB) - added by afercia 16 months ago.
33902.3.patch (15.4 KB) - added by azaozz 7 months ago.

Download all attachments as: .zip

Change History (50)

@afercia
21 months ago

#1 @afercia
21 months ago

  • Keywords has-patch added

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.

https://cldup.com/E51OPwBpeP.png

https://cldup.com/qU0lxqsPar.png

#2 @joedolson
21 months ago

This should possibly be addressed alongside #27555

#3 follow-up: @boonebgorges
21 months 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 @helen
21 months 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 @joedolson
21 months 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: @boonebgorges
21 months 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: @afercia
21 months 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 @boonebgorges
21 months 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.


20 months ago

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


19 months ago

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


16 months ago

@afercia
16 months ago

#12 @afercia
16 months ago

Refreshed patch after recent changes. Also fixes an untranslatable string.

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


16 months ago

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


15 months ago

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


12 months ago

#16 @afercia
12 months ago

#32598 was marked as a duplicate.

#17 @afercia
12 months 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.

Last edited 11 months ago by afercia (previous) (diff)

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


11 months ago

#19 @afercia
11 months 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.

#20 @afercia
9 months ago

  • Keywords early removed
  • Milestone changed from Future Release to 4.7

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


8 months ago

#22 @desrosj
8 months ago

This may need a patch refresh. This should start moving to avoid being punted.

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


8 months ago

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


8 months ago

#25 @afercia
8 months 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.


7 months ago

@azaozz
7 months ago

#27 @azaozz
7 months 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.

Last edited 7 months ago by azaozz (previous) (diff)

#28 @afercia
7 months 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:

https://cldup.com/rkDTqypw5Q.png

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.


7 months ago

#30 @afercia
7 months ago

Note: I'd change the CSS class wplink-autocomplete in wp-tags-autocomplete

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


7 months ago

#32 @afercia
7 months 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: @afercia
7 months 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 @azaozz
7 months 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',
		),
	) );
}

#35 @azaozz
7 months ago

In 38797:

Accessible Tags autocomplete:

  • Replace suggest.js with UI Autocomplete.
  • Use the same settings like in the editor link toolbar.
  • Abstract it and add in a new file, tags-suggest.js. Then make it a dependency for the Tags postbox(es) and Quick and Bulk Edit.
  • Add data-wp-taxonomy on all input elements to improve handling in the UI for custom taxonomies.

Props afercia, azaozz.
See #33902.

#36 in reply to: ↑ 33 @azaozz
7 months 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.


7 months ago

#38 @afercia
7 months 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.


7 months ago

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


7 months ago

#41 @afercia
7 months 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:

https://cldup.com/qPcosAr7O7.png

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.

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


7 months ago

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


7 months ago

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


7 months ago

#45 @helen
7 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

@afercia: Seems like this is probably worth a separate ticket to track the remaining case, leaving that unmilestoned until there's a solution. Closing this as fixed for 4.7.

#46 @afercia
7 months ago

Yep, thanks @helen will open a new ticket.

#47 @afercia
5 weeks ago

#38094 was marked as a duplicate.

Note: See TracTickets for help on using tickets.