Make WordPress Core

Opened 6 years ago

Last modified 4 months ago

#35483 assigned defect (bug)

Accessibility improvements for the Bulk Edit form

Reported by: afercia Owned by:
Milestone: 5.9 Priority: normal
Severity: normal Version:
Component: Quick/Bulk Edit Keywords: has-patch has-screenshots title-attribute
Focuses: ui, accessibility, javascript Cc:


Splitting this out from #34756.

In order to make the Bulk Edit usable with a keyboard, all controls should be built with elements that natively support keyboard interaction. The delete "X" links should be buttons and the actionable area should be a bit bigger, thinking also at the responsive view on smaller screens.

When opening the form, focus should be moved to the first focusable form element:


The list of items should be marked up as a list, so screen readers will announce the total number of items selected.

Title attributes should be removed from the items titles in favor of aria-label attributes that should contain the item title e.g.:

'Remove %s from Bulk Edit'

Worth noting post titles might contain emojis and special characters that should be removed or escaped before being used in a HTML attribute:


When removing items from the list, focus should be moved to the previous or next item and when there are no more items, probably to the "Cancel" button.

Adding a role=form and an aria-labelledby attribute will make screen readers announce the "Quick Edit" legend. I'd propose to add a description for the tags textarea, for semantics, accessibility, and also for consistency with other Tags boxes in the admin.

Lastly, I'd strongly recommend to make the font-size a bit bigger :) Currently, it's set to 12px and for some labels to 11px, I'd say definitely too small for today's screens.

Attachments (2)

35483.patch (10.5 KB) - added by afercia 6 years ago.
35483.2.patch (13.4 KB) - added by afercia 6 years ago.

Download all attachments as: .zip

Change History (19)

6 years ago

#1 @afercia
6 years ago

  • Keywords has-patch has-screenshots added
  • Owner set to afercia
  • Status changed from new to assigned

First pass. In the screenshot below, NVDA reading out content while opening the form and navigating and removing items from the items list. Also, the patch uses wp.a11y.speak() to dispatch to screen readers an audible confirmation message when removing items.


Would greatly appreciate feedback about the best way to escape and clean up from Emojis the string to use as aria-label cc @azaozz :)

#2 follow-up: @azaozz
6 years ago

Few things:

  • Focusing on the first "remove" button seems wrong. This is far from being the "default" action. Users open Bulk Edit to change some post settings, not to remove posts from there :)
  • Making the whole post title inside the bulk edit list clickable doesn't work well. The "active" part there should be only the (x) icon as before. It is too easy to remove a post from bulk editing by clicking the that title by mistake.
  • The "structural" css needs a bit more work. I agree the purpose here is not a complete refactoring but making the right half a bit more responsive would be much better.

When removing items from the list, focus should be moved to the previous or next item and when there are no more items, probably to the "Cancel" button.

Thinking we should standardize on either the previous or the next (if both exist). We should probably close Bulk Edit when no more items left. New items cannot be added there.

Would greatly appreciate feedback about the best way to escape and clean up from Emojis the string to use as aria-label.

To escape we only need to do $( element ).text(). Not sure about removing emoji and other special chars from the post titles. They are in the titles in the list-table and will be in the titles on the front-end. Perhaps we should wrap the copied post titles in spans with auto-generated IDs and use aria-labelledby? Then a "row" in the Bulk Edit list would look like:

<li><button aria-labelledby="bulk-edit-1">Remove (hidden offscreen)</button><span id="bulk-edit-1">Copied post title</span></li>
Last edited 6 years ago by azaozz (previous) (diff)

#3 in reply to: ↑ 2 @afercia
6 years ago

Replying to azaozz:

To escape we only need to do $( element ).text().

Thanks @azaozz will try to address all the points. About escaping/encoding, tried that as first thing but if I'm not wrong characters like ">" will be treated like text so won't be encoded and will be used as ">" within the aria-label attribute, breaking the HTML :(

#4 @afercia
6 years ago

I just wanted to make this form usable with a keyboard ;) but yep, seems there are many usability issues to solve. Will try to be as short as possible and maybe it would be nice to discuss this a bit longer on Slack.

Initial focus
Should be set on the first form element. If in a linearised workflow like when using only the keyboard the remove buttons feel wrong as first thing, then I'd say they shouldn't be the first thing in the form in the first place. It's a bit tricky since many form elements get printed out conditionally, depending on the features supported by the post, user capabilities, how many registered taxonomies... For example, when a post type doesn't support title what is printed out is, err.. this:


Maybe move the titles at the end of the form as a last check to do before saving would make more sense? We're moving towards a complete refactoring though :)

"Remove buttons" size
Sure, they can use just the "x", thinking on small screens they should be at least 40x40 pixels though.

Move focus to the previous or next remove buttons
Thought it's already the previous one by default? If there's no previous one, will use the next one.
Automatically closing the form when no more items left would be a bit confusing for screen reader users I guess, not sure about this but worth experimenting a bit, maybe using also an audible message

The "structural" css needs a bit more work
I agree. Maybe open a separate ticket? Would need a re-think since many elements are printed out conditionally (see above)

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

6 years ago

6 years ago

#6 @afercia
6 years ago

Second pass:

  • the "remove buttons" are now smaller (just the "X")
  • when removing items and no more items left, the form closes and an audible feedback message gets dispatched to the WP Speak live region
  • first round of CSS improvements, especially for the responsive view

Still to discuss: initial focus and the bulk titles list.

#7 @afercia
6 years ago

#35549 was marked as a duplicate.

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

6 years ago

#9 @afercia
6 years ago

  • Milestone changed from 4.5 to Future Release

I'm afraid I won't have so much time in the next couple weeks to look at this, moving to future release. If someone wants to take a stab at this, please do feel free to re-milestone.

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

5 years ago

#11 @joedolson
5 years ago

Discussed this in the #a11y meeting today, and agreed that there are only two practical options for an initial focus.

1) Add a 'cancel' button as the first focus item, with text like Bulk editing ''n'' posts. Cancel?

2) Add a focusable paragraph with text like Bulk editing ''n'' posts., to give people context for where they've landed.

This is an important change for usability of bulk editing for accessibility, so this needs to be settled in some way. The focusable paragraph doesn't necessarily need to be visible, as this is primarily to provide a keyboard focus landing point and screen reader context.

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

4 years ago

#13 @joedolson
4 years ago

Identifying the initial focus is definitely challenging, and we need to start thinking a little out of the box. I think we should treat this panels similarly to a modal, and assign an initial focus to 'cancel', constraining focus within the bulk edit panel while it's open. This would give us a clean, actionable initial focus, and potentially simplify the overall editing experience for many users.

#14 @afercia
3 years ago

  • Owner afercia deleted

#15 @afercia
17 months ago

  • Keywords title-attribute added

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

4 months ago

#17 @joedolson
4 months ago

  • Milestone changed from Future Release to 5.9
Note: See TracTickets for help on using tickets.