Minor UI improvements to bulk editing

[siobhan]

The bulk editing feature isn't particularly clear. For example, it's odd that you can have a bunch of posts selected, leave "bulk editing" selected (the default in the dropdown, and just click the "Apply" button and nothing happens. The seems like odd behaviour (related: #11818).

The other niggle is the word "Apply" on the button. You're not actually applying anything when you click the "Apply" button, you're either a) making a selection of things that you are going to go on and apply things to, or b) moving things to trash. The "Apply" button doesn't accurately reflect that action (it seems to make more sense in the spam screen as you are actually taking actions in which an application is made.

I suggest the following minor improvements:

When the default of "Bulk Actions" appears in the dropdown the "Apply" button is greyed out and not pressable. When the user selects either "Edit" or "Move to Trash" the button becomes clickable.

The terminology on the button is changed from "Apply" to "Go", or "OK" or something other than Apply. I'm scratching my head to try to think of something :)

[helen]

This has bugged me for a while, and I just came across it again as I was testing comments, where if you just ran a bulk action on some items and apply a bulk action again, it says that it's run that bulk action for X items even though you haven't actually selected them again (which is bad and also needs to be fixed). We should definitely gray out bulk actions until something is selected, and disable the button until a bulk action is selected. I do think "Apply" is okay (apply this action to all of my selected items), but open to suggestions.

[pareshradadiya]

Patch added

[pareshradadiya]

Apply button is in disable state. It would get enable once you have atleast one row is selected and Bulk Actions(the default selected item in the dropdown) is not selected in the dropdown

[pareshradadiya]

Patch updated

[pareshradadiya]

Code is moved to common.js to make it work for all wp-list-table

[pareshradadiya]

Replying to helen:

This has bugged me for a while, and I just came across it again as I was testing comments, where if you just ran a bulk action on some items and apply a bulk action again, it says that it's run that bulk action for X items even though you haven't actually selected them again (which is bad and also needs to be fixed). We should definitely gray out bulk actions until something is selected, and disable the button until a bulk action is selected. I do think "Apply" is okay (apply this action to all of my selected items), but open to suggestions.

If we gray out bulk action then still Apply button is clickable. so it would be better to disable Apply button until some rows and bulk action is not selected.

[wonderboymusic]

31634.3.diff​ is a reboot

[wonderboymusic]

In 34467:

List Tables: add JS code to dynamically toggle the disabled attribute of the Bulk Actions dropdown and Apply button.

Props wonderboymusic, pareshradadiya.
Fixes #31634.

[afercia]

Reopening cause there are some accessibility concerns here, would like to hear the accessibility/UI teams opinion about this. Most notably:

• discoverability for screen reader users: disabled controls are skipped when tabbing
• browsers fire the "change" event on select elements in different ways, see for example a similar issue in #30333 then reverted

About the second issue, please try this using Firefox:

• check some posts in the Posts screen
• use the Tab key to focus the Bulk Edit select
• don't expand the select but just change the selected option using the arrow keys
• press Tab
• the "Apply" button is skipped (no change event fired)

The same thing happens when you expand the select, use the arrow keys to change the selected option and then press Tab.

If you try this using Chrome or IE, you will notice that they do fire the change event when changing the selected option with the arrow keys. Worth noting that, according to the specs, the correct behavior is the Firefox one.

[johnjamesjacoby]

Totally anecdotal feedback about disabling bulk actions when no rows are checked: something about it being disabled by default draws attention towards those elements instead of away from them. In a client meeting this week, I witnessed 3 individuals attempt to click the disabled "Bulk Actions" dropdown, in what I suspect was confirmation it was actually not an available option to them, and to learn what they needed to do to enable it, to then figure out what the options were that were available to them. Does that make sense?

Is it possible to user-test this in a more formal capacity? I'm happy to help with efforts towards usertesting.com feedback, or some other method if it's preferable.

[afercia]

Replying to johnjamesjacoby:

Is it possible to user-test this in a more formal capacity?

+1

[johnjamesjacoby]

Buttons in plugins unrelated to bulk actions being disabled by this JavaScript (WP Event Calendar plugin, in this example)

[DrewAPicture]

@afercia Are you by chance working on a patch incorporating your feedback here? Seems like there's some concern from @johnjamesjacoby about possibly unexpected behavior following this change.

[afercia]

No patch for now and couldn't think of a real "fix": as I see it, either we do this change or we should revert it. We discussed a bit this in our last Slack chat: ​https://wordpress.slack.com/archives/accessibility/p1444069695000106 and probably will ask our testers group to give us some feedback.

Personally, I'm not sure this change is a good thing. I'm afraid it would be confusing for users and what happened in @johnjamesjacoby client meeting is enlightening, while anecdotal.

Worth noting there are other places where there's a similar select that "does nothing" until you check something, for example in the Users screen the "Change role to..." select. So should we introduce this change there and for all similar cases too? See screenshot below, it's not clear to me why the Bulk Actions select is disabled and the roles one is not:

I'd like to wait for some testing feedback. Personally I'm inclined to recommend to revert this and maybe we should consider to investigate on the real reasons why the interaction with this control feels odd.

[afercia]

Just noticed one edge case:

• Plugins screen
• select a couple of plugins
• choose "Delete" from Bulk Actions and press "Apply"
• you get a confirmation screen
• press the "Back" button in your browser
• in the Plugins list you still have the Plugins checboxes selected but the Bulk Edit select is disabled

[rianrietveld]

Hi all, the accessibility test team looked at this and here are there results (summary at the bottom):

Tested on: WordPress 4.4-alpha-35151

Geof Collis with IE 11, latest Firefox JAWS 14.5:
Bulk edit move to trash is easiest enough to do, but what I'd like is the focus to be taken to the message that it was completed. After I clicked apply I'm not sure what happened, I was taken to the top of the page and had to heading down to find the text that they had been moved.

Shaun Everiss with NVDA FireFox:
Looks ok no issue

Gabriela Nino with VoiceOver + Safari

When only one post is selected the button become clickable. I think it should be clickable when at least two posts are selected, since doing a bulk action for only one post does not make sense.

I found the bulk editing feature more clear this way. I agree it should be disabled if no more than two posts are selected. But the feature is lacking two important things:

1: An easier way to navigate from the posts to the actions
It takes time to review the list of posts, the user needs to pass over each line of the table to listen to the post title and proceed to select it. It would be nice to have a shortcut for the Bulk actions for example on the post menu (edit - Quick edit – Trash - View – Bulk editing) so the user does not require to move back until the she finds the Bulk button. With VoiceOver, I'm able to navigate using the rotor, but first I have to select “Form controls” menu and then listen to the options to find the button “Bulk editing”

2: Give feedback to the user when edit or move to trash action is applied
After clicking on the “Apply” button there is none feedback for the user. “Edit” open a "Bulk edit" section, but the user is not informed. The “Move to trash” action shows an information message at the top of the page, the user is not aware of it (I agree with Geof).

Michelle DeYoung with Firefox and NVDA
These are my suggestions for hopefully making it more understandable to screen reader users.
I think this case can benefit from having more instruction voiced to the user rather than less.
The idea is to programmatically toggle the label that is voiced by screen readers when the item is available or disabled.

When Bulk Action is disabled:

<div class="alignleft actions bulkactions">
<label class="screen-reader-text" for="bulk-action-selector-top" style="display:none;">Select bulk action</label>
<label class="screen-reader-text" for="bulk-action-selector-top">Select bulk action will be available when selections are made from the table below.</label>
<select id="bulk-action-selector-top" name="action" disabled="">
<option value="-1">Bulk Actions</option>
<option class="hide-if-no-js" value="edit">Edit</option>
<option value="trash">Move to Trash</option>
</select>
<input id="doaction" class="button action" type="submit" value="Apply" disabled="">
</div>

When Bulk Action is available:

<div class="alignleft actions bulkactions">
<label class="screen-reader-text" for="bulk-action-selector-top">Select bulk action</label>
<label class="screen-reader-text" for="bulk-action-selector-top" style="display:none;">Select bulk action will be available when selections are made from the table below.</label>
<select id="bulk-action-selector-top" name="action">
<option value="-1">Bulk Actions</option>
<option class="hide-if-no-js" value="edit">Edit</option>
<option value="trash">Move to Trash</option>
</select>
<input id="doaction" class="button action" type="submit" value="Apply" disabled="">
</div>

For the table selections:
For the checkboxes in the table, I also think a bit more information on the "Select All" label could help.

<table class="wp-list-table widefat fixed striped posts">
<thead>
<tr>
<td id="cb" class="manage-column column-cb check-column">
<label class="screen-reader-text" for="cb-select-all-1">"Select All" to perform a bulk action on all items or select individual items below to perform a bulk action on.</label>
<input id="cb-select-all-1" type="checkbox">
</td>

Ruth Nisenbaum
Keyboard only on Firefox

It looks clear to me.
I have a usability keyboard problem, when I want to move through the different posts, to go to the next post, I have to click 8 times the tab button.
Would it be possible to have a skiplink from post to post that would enable me to jump to the next post instead of clicking 8 times?

Summary

1. Better feedback for screen reader users about what to expect and what happens (see also code examples Michelle)
2. The button should become clickable when at least two posts are selected, since doing a bulk action for only one post does not make sense.
3. If possible a more usable tab order to select posts

So: no show stoppers, but more feedback and usability would be welcome.

[afercia]

After our testers reports, which also point out some additional issues, we've discussed a bit this ticket ​in today's accessibility team chat on Slack. TL;DR we'd recommend to revert the automatic enabling and disabling of the select/button.

We see there's room for improvement and the original intent of this ticket is for sure something worth considering. By the way we feel the current implementation introduces even more potential confusion for users.

Maybe users just need instructions about how this works. Maybe worth exploring new ideas and do some research and usability tests before introducing any change here.

One small, marginal, improvement emerged from the discussion: consider to add an ellipsis to the "Bulk Actions" string that would give a little hint to users they actually have to select something and also for consistency with other similar selects:

[wonderboymusic]

In 35277:

List Tables: revert the majority of [34467]. This was almost universally abhorred (the JS that disabled the bulk dropdowns).

See #31634.

[gsarig]

Regarding Batch updating of installed plugins, I believe that the select menu could be friendlier. For example, I think that the buttons “update”, “activate”, “deactivate” and “delete” could just be a simple horizontal list. Buttons would be inactive if no plugin is selected and active when one or more plugins were checked. Here’s a small screenshot of what I suggest:

That way we could minimize the number of clicks to perform an action from 4 (check, select, option, apply) to just 2 (check, apply).

Some other thoughts on that:

• I believe that different actions should have a different visual. For example, "update" is something that we might want to encourage, which is not the case for "delete". Therefore, the "update" button could have a more distinctive visual (e.g. the typical blue button), while the "delete" could be just a simple red link.
• We could also make it even smarter by keeping, for example, the “activate” button disabled if all checked plugins are already active, otherwise it would remain disabled.
• If we assume that the "update" button is indeed something that we would like to encourage, perhaps it could be active anyway. If nothing is checked, it could say "Update all" and if one or more plugins get selected, could become "Update selected".

[afercia]

#37350 was marked as a duplicate.

[sagarprajapati]

Hi Team,

I have worked on above all the above listed suggestions.

According to @helen suggestion, I have disabled the apply button if user has not selected any checkbox and also selected the dropdown value is "Bulk Actions".

When the user selects anything other than "Bulk Actions" and at list one checkbox is selected then "apply" button will visible.

From Accessibility point of view, @afercia suggestion we have tested the below point and it's working fine.

Firefox:
1) check some posts in the Posts screen
2) use the Tab key to focus the Bulk Edit select
3) don't expand the select but just change the selected option using the arrow keys
press Tab
4) the "Apply" button is skipped

Also check in plugin screen that when we click on back button it goes to previous page.
1) select a couple of plugins
2) choose "Delete" from Bulk Actions and press "Apply"
3) you get a confirmation screen
4) press the "Back" button in your browser
in the Plugins list you still have the Plugins checboxes selected but the Bulk Edit select is disabled

Please check the above patch and let me know your feedback.

Thanks

[afercia]

Re: the issue with the different implementation of the onchange event across browsers, seems something changed in Firefox between version 48 and 49. In Firefox 48, the onchange event doesn't fire when using only the keyboard. In Firefox 49 does fire. To me, this seems a regression in Firefox and I've just opened a ticked on bugzilla, see ​https://bugzilla.mozilla.org/show_bug.cgi?id=1350700

Worth considering that MDN still refers to the implementation Firefox used to have in the last 15 years or so :) See: ​https://developer.mozilla.org/en-US/docs/Web/Events/change

For example, keyboard navigation in <select> elements never fires a change event in Gecko until the user hits Enter or switches the focus away from the <select> (see bug 126379).

I'd recommend to wait for a reply on the bugzilla ticket before making any decisions here.

Other than this, the onchange event on select elements is tricky and there are other edge cases that can still be reproduced, both in Firefox for Mac or Win. For example, using Firefox 52.0.1 on a Mac:

• apply the latest patch
• go in the Posts screen
• check a couple post checkboxes
• using only the keyboard, focus the Bulk Edit select
• press the Down Arrow key to open the select
• press again the Down Arrow to select "Edit"
• with the select still open, press the Tab key

result: focus moves to the "dates" select and the Apply button gets skipped.

Worth reminding the select elements behaviour varies depending on the platform and the browser used. On Windows for example, using the Down Arrow key doesn't open the select.

Other considerations:
(some of them are from previous comments)

The Apply button should be enabled when at least two posts are selected, since doing a bulk action for only one post does not make much sense.

The issue about the Plugins screen mentioned in comment 19 doesn't happen any longer since Shiny Updates has been introduced in core; however, it still happens on the Users screen. To reproduce:

• select two users for deletion
• select "Delete" from the dropdown
• click Apply
• you're now in a "Delete Users" screen
• press your browser's back button
• users are still selected, the dropdown is still on "Delete" but the Apply button is disabled

Consider to give better feedback for screen reader users about what to expect and what happens, for example add some explanation, something along the lines of "bulk actions will be available when selections are made from the table below"

@sagarprajapati thanks for the patch! A few things:
When there's no support for JavaScript, the Apply button will be always disabled thus users won't be able to submit any action. This is something that was missed in the previous patches too :) The disabled state should be set via JS and not in the HTML.

This part won't work in the Plugins screen after a plugin search:

$body.on( 'change', '#bulk-action-selector-top, #bulk-action-selector-bottom', function( event ) { 
	actions.not( this ).val( this.value );
	setApplyButton( event );
});

When doing a plugin search, the table gets re-injected via JS so the select elements are new objects while actions still refers to the select elements that were in the page on DOM ready. Result: the select are not synced and the buttons are still disabled, see screenshot below:

The patch would need some ​JS coding standards. I'd suggest to run jshint which is very handy to check for syntax typos and so on. For example, you can run:
grunt jshint:core --file=common.js to check a single file.

[sagarprajapati]

Hi @afercia

Thank you for reviewing my patch.

I have worked in your suggestions and fixed it. Please check above attached patch.

Below I have described all the points.

Firefox 48 Issue

To solved firefox 48 issue I have added a key event for the select dropdown.

Enable apply button when two or more checkbox selected

Fixed back button issue on user screen

Set the disable state by Js not by HTML

Solved Plugin search issue.

I have solved all the issue of js coding standards which is suggested by jshint.

Thanks

[afercia]

@sagarprajapati thanks for the refreshed patch! I'd suggest to see if the ​Mozilla bug has some progress soon before moving on with this ticket.

[sagarprajapati]

Hi @afercia

Thank you for the response. But I have resolved Mozilla Browser version-48 issue. In my previous comment, I have attached a latest patch. Please guide me, If I am wrong in any place.

Thanks

[afercia]

Related: #40925

[joedolson]

Taking ownership to look this over and try to reach a resolution.