WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 months ago

Last modified 4 months ago

#39074 closed defect (bug) (fixed)

No method to move meta boxes using keyboard

Reported by: joedolson Owned by: afercia
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: Administration Keywords: wpcampus-report has-screenshots has-dev-note
Focuses: ui, accessibility Cc:

Description (last modified by antpb)

Using a mouse, meta boxes can be moved to a new order in the DOM or to a different column. There's no method to do this using the keyboard.

Especially with several plugins installed, being able to customize which meta boxes are closest in tab sequence can be quite helpful for editing efficiency.

I assume this has been in since whatever version added sortable metaboxes.

EDIT BY ANTPB:
This issue was brought to light again through the WPCampus-report when it was discovered that the weight of the edit image attributes was not able to be ordered. This is true for all forms of meta boxes so I’m adding in the details from the specific Edit Image context to highlight the accessibility importance of this issue:

Moved from the WPCampus accessibility report issues on GitHub, see https://github.com/WordPress/gutenberg/issues/15316

Severity:
Low
Affected Populations:
Blind
Motor Impaired
Platform(s):
All / Universal
Components affected:
Edit Media
Issue description
The Edit Media interface* includes the ability to re-arrange the boxes by
drag and drop, however this can only be achieved by mouse users, since
the functionality does not support touch or keyboard users.

Users of touchscreens and keyboards cannot re-order the boxes. Speech
recognition users may be able to if they can manipulate the mouse with
speech (such as using Mouse Move), however this is onerous and
difficult.

Remediation Guidance
Allow keyboard and touchscreen users the ability to re-arrange the
boxes. This can either be done with dedicated buttons, such as are used
within Gutenberg for moving Blocks; or it could be done by extending
drag and drop support to keyboard and touch users (a good example of
which is dragondrop: https://schne324.github.io/dragon-drop/demo/).

Relevant standards

2.1.1 Keyboard (Level A) https://www.w3.org/TR/WCAG20/#keyboard-operation-keyboard-operable
Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-80 in Tenon's report

*Original issue description and screenshot are available at page 142 of the complete technical report PDF. However, the screenshot appears to be related to the edit post screen in the classic editor.
https://github.com/WordPress/gutenberg/issues/15316#issuecomment-489460963

Attachments (31)

4A1B714B-6886-470C-BD7C-313BA317BDE7.png (76.9 KB) - added by antpb 15 months ago.
An example where this has accessibility difficulties
39074.diff (3.7 KB) - added by xkon 11 months ago.
39074_preview.gif (2.4 MB) - added by xkon 11 months ago.
39074.2.diff (4.6 KB) - added by xkon 11 months ago.
39074.2_preview.jpg (49.9 KB) - added by xkon 11 months ago.
e023d824fba3497e5f81cd1f5ed80441.gif (916.5 KB) - added by audrasjb 11 months ago.
Testing xkon’s patch
39074.3.diff (5.5 KB) - added by xkon 11 months ago.
39074.3_preview.gif (620.3 KB) - added by xkon 11 months ago.
advanced meta-box-sortable with height 0.png (202.5 KB) - added by afercia 10 months ago.
39074.4.diff (7.6 KB) - added by xkon 10 months ago.
39074.4_preview.gif (348.8 KB) - added by xkon 10 months ago.
39074.5.diff (8.2 KB) - added by xkon 10 months ago.
39074.5_preview.gif (2.7 MB) - added by xkon 10 months ago.
39074.6.diff (10.9 KB) - added by xkon 10 months ago.
39074.6_preview.gif (710.8 KB) - added by xkon 10 months ago.
39074.7.diff (13.3 KB) - added by xkon 10 months ago.
39074.8.diff (14.6 KB) - added by xkon 10 months ago.
39074.8_preview.gif (1022.6 KB) - added by xkon 10 months ago.
39074.9.diff (16.5 KB) - added by afercia 5 months ago.
39074.png (84.4 KB) - added by afercia 5 months ago.
Example of the new buttons on the Dashboard
39074.10.diff (17.0 KB) - added by afercia 5 months ago.
39074.11.diff (16.5 KB) - added by afercia 5 months ago.
39074.12.diff (2.8 KB) - added by afercia 5 months ago.
39074 boxes moved to the ACF sortables area before the post title.png (181.6 KB) - added by afercia 5 months ago.
Boxes moved to the ACF sortables area before the post title
postbox-arrows.png (21.6 KB) - added by azaozz 5 months ago.
postbox-arrows-outline.png (18.5 KB) - added by azaozz 5 months ago.
dashboard-after-48465.png (43.2 KB) - added by azaozz 5 months ago.
edit-post-after-48465.png (22.2 KB) - added by azaozz 5 months ago.
39074 clickable area before.png (17.3 KB) - added by afercia 5 months ago.
Clickable area before: 36 by 36 pixels and consistent for all buttons
39074 clickable area after.png (15.3 KB) - added by afercia 5 months ago.
Clickable area after: smaller and inconsistent
39074 WooCommerce Orders meta box.png (66.1 KB) - added by afercia 4 months ago.
WooCommerce Edit order page: the "Order data" customized meta box

Change History (121)

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


4 years ago

#2 @afercia
4 years ago

  • Milestone changed from Awaiting Review to Future Release

Makes sense and probably needs some research.

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


3 years ago

#4 @afercia
18 months ago

Related: #47135.

This ticket was mentioned in Slack in #core-media by mike. View the logs.


15 months ago

#6 @anevins
15 months ago

  • Keywords wpcampus-report added; needs-patch removed

Added keyword

#7 @antpb
15 months ago

#47135 was marked as a duplicate.

#8 @antpb
15 months ago

  • Description modified (diff)

#9 @antpb
15 months ago

  • Milestone changed from Future Release to 5.3

@antpb
15 months ago

An example where this has accessibility difficulties

#10 @afercia
15 months ago

Full detailed report available at #47135.

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 audrasjb. View the logs.


15 months ago

#13 @audrasjb
15 months ago

  • Keywords needs-design added

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


15 months ago

#15 @anevins
15 months ago

Hey @antpb we were just wondering whether you envisaged a particular solution when this was moved to 5.3.

If you haven't envisaged a solution, I mentioned that we could look at taking what Drupal does with 'row heights'. It's a very primitive win to the problem, but it could be used as a step forward to a more beautiful solution. The 'row heights' functionality provides a numeric input field and changing the number (and submitting) changes the order of the field.

Ideally we need to have an envisaged solution before going to design, otherwise we could see a lot of back and forth that we might not have time for in this 5.3 release.

#16 @afercia
15 months ago

  • Component changed from Administration to Editor
  • Focuses ui administration added

Discussed during today's accessibility bug-scrub: agreed that the "Administration" component doesn't help this ticket to get much attention. Changing component to "Editor" though it is related to "Media" as well.

#17 @davidbaumwald
15 months ago

This ticket needs direction, and with 5.3 Beta 1 in three days, this is being moved to Future Release. If this can be resolved in time, feel free to revert the milestone back to 5.3.

#18 @davidbaumwald
15 months ago

  • Milestone changed from 5.3 to Future Release

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


14 months ago

#20 @afercia
14 months ago

  • Keywords needs-patch added
  • Milestone changed from Future Release to 5.4

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


11 months ago

@xkon
11 months ago

@xkon
11 months ago

#22 @xkon
11 months ago

  • Keywords has-patch added; needs-patch removed

39074.diff makes a small start as a proposal.

It adds 2 extra buttons as handle-order-next and handle-order-prev on the meta box header.

For the time being it doesn't handle area changing as well, you can re-order only within the same "group" of meta boxes.

Note that since the buttons are within the $wp_meta_boxes the same rules apply everywhere that they are used, so this is expanded to Dashboard also as well not only Page editing :).

Unfortunately, I had trouble keeping the focus on the button that was selected via the keyboard, I'm not sure how this is possible but do tell me if we could somehow fix that and I'll be happy to continue the patches here if we're on a good start.

For the time being, I just used the same dashicon but I'm pretty sure that it might be a bit confusing as it would be better for them to be pointing "up/down" instead but I wanted them to be different than the open/close one that already exists.

@xkon
11 months ago

#23 @xkon
11 months ago

39074.2.diff adds some extra CSS to be more in line with the existing toggle as well, updates the dashicons to use the same arrows as in block editor sorting and also addresses the focus issue from my previous comment.

#24 @MarcoZ
11 months ago

This looks good to me from a screen reader perspective.

@audrasjb
11 months ago

Testing xkon’s patch

#25 @audrasjb
11 months ago

The patch works fine, thanks @xkon !

I'm wondering if we should add a visual focus state (which would just be some visual CSS styles) to the whole metabox container so users could visually identify what is the currently focused metabox?

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


11 months ago

@xkon
11 months ago

#27 @xkon
11 months ago

  • Keywords 2nd-opinion added

39074.3.diff adds a "pseudo class" of .focused to be used along with .postbox to have a visual representation of which postbox is moved as we wanted to explore this from comment 25.

I don't know if this is entirely correct as this catches all click and keyup (bound to Tab only) events on body so we can focus/unfocus the postboxes as well depending on where the mouse or current tabbing is.

You can see a preview of both tabbing + clicking at 39074.3_preview.gif.

If this approach isn't optimal, I'll see if I can bind the overall postbox focus only when the sorting buttons are used instead :).

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

#28 @audrasjb
11 months ago

Thanks @xkon, the patch looks perfect to me!
Any thoughts on the last proposed patch @afercia?

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


11 months ago

#30 @audrasjb
11 months ago

  • Keywords needs-design-feedback added; needs-design removed
  • Owner set to xkon
  • Status changed from new to assigned

#31 @afercia
10 months ago

  • Keywords 2nd-opinion removed

Looking a bit into patches 2 and 3:

I don't know if this is entirely correct as this catches all click and keyup (bound to Tab only) events on body so we can focus/unfocus the postboxes as well depending on where the mouse or current tabbing is.

Yep, I'd tend to think it's a bit too much :) The blue outline is also displayed when normally tabbing within a meta box, which doesn't feel correct. Not sure the moved box needs an additional visual indication to start with, because focus is already on one of its move buttons. Anyways, we can maybe explore a lighter, simpler, visual indication. Maybe an animation à la Gutenberg?

you can re-order only within the same "group"

Maybe it wouldn't be so hard to implement. By using something like:

$( '.meta-box-sortables .postbox' ).index( closestPostbox )

it is possible to get the index of the "to be moved" meta box within the collection of all meta boxes in a page. At that point, it is possible to select the previous or next meta box by its index. This would allow move a meta box through all the meta boxes in a page, in a sort of "loop". Then, some logic should be implemented when the moved meta box enters in a new group so that it is moved to the correct position. I played a bit with this and I think it can be done :)

From an accessibility perspective there are a few things to address. They can be done later, when the functionality is stable. For example:

  • the visual order of the buttons doesn't match the DOM order: this is partially a pre-existing issue but it's more evident now with the new buttons
  • the buttons text should be greatly simplified, especially for speech recognition software users
  • it would be nice to use a speak() message when the order is saved successfully: I'd modify the AJAX action to use wp_send_json_success() with a short message and then use that for speak()
  • when a meta box is at the first position, the "Move up" button should be disabled
  • similarly when it's at the last position, the "Move down" button should be disabled

Note: disabled or removed? In any case, there should be some textual information to communicate to users why the box can't be further moved.

As said, these things can be done later.

From a code perspective, I'd suggest to bind to the new buttons new specific click events and separate, new, callbacks instead of reusing the event that is only meant to collapse/expand the boxes. Basically: not put everything inside handle_click().

#32 @afercia
10 months ago

  • Keywords has-screenshots added

Aside: I also noticed what is possibly a pre-existing bug. Seems to me that in the Edit post page it's basically impossible to move a meta box to the "Advanced" area. This area has a height = 0 so the jQuery UI sortable can't work. See the attached screenshot below, where I highlighted the "side". "normal", and "advanced" areas to illustrate the issue.

#33 @xkon
10 months ago

Thank you for the detailed reply @afercia!

I'm already working towards a new patch and I'll try to sort out as much as possible from anything you've noticed. It will be easier if we can handle even some of the "after" steps now as they seem to be easy changes that will also pass throughout all wp-admin area :).

I'll upload an updated version asap.

@xkon
10 months ago

#34 @xkon
10 months ago

39074.4.diff is a "restart" following the feedback from comment 31.

  • CSS classes for buttons are now handle-order-higher, handle-order-lower and their indicators as order-higher-indicator and order-lower-indicator to avoid the usage of Toggle.
  • The screen reader texts have been adjusted to 'Order %s panel lower' and 'Order %s panel higher'.
  • The buttons now have an aria-disabled attribute with a true/false value depending on their position on page load which is being updated on click depending on the case if ordering higher/lower is possible.
  • Regarding the JS a handle_order has been created to avoid using the existing handle_click and split up these actions on their own.
  • Further adjustments have been made to CSS & template.php to group the 3 handles into a div to match the DOM with the visual order.

---

@afercia if we go towards the way of allowing postboxes to move between groups as well, there's no need for a disabled move higher/lower button as essentially like you said it will be in a loop. I do think though that for now we should keep the boxes in the same groups and see a full cycle maybe after 5.4 (?).

Regarding the advanced group, I think we should make it to 36px by default (that's the height of a postbox heading) and add a visual border similar to what an empty group has on Dashboard. Since there's no border at all even if we adjust the height there will still be no visual indication that an extra group exists. Would that be ok?

---

Remaining suggestions for next patch:

  • Adjust the aria-disabled of all postboxes in the same Sortables region as at the moment in some cases they might remain disabled.
  • Use a speak() message when the order is saved successfully via Ajax.
  • Advanced group (if not decided to be split on a different ticket).
  • Any other fixes from further comments :-).

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


10 months ago

@xkon
10 months ago

#36 @xkon
10 months ago

39074.5.diff goes a step further from .4 and introduces enable_disable_order_buttons as well that is fired on both drag & drop actions or while clicking any of the order buttons.

This ensures that if a postbox is dragged on a different group all of the ordering buttons will be readjusted as enabled/disabled according to the new order of each meta-box-sortables group.

Please feel free to test and give feedback at this since all the major parts have been applied, the functionality most likely (and hopefully 🤞) won't change much from this point on.

Already working on further patches exploring ways to introduce speak() and a possible non-confusing way of moving postboxes between groups via a button as well.

#37 @xkon
10 months ago

I've created a new ticket regarding the issue mentioned here of the advanced-sortables missing their border. Please see #49288.

@xkon
10 months ago

#38 @xkon
10 months ago

39074.6.diff adds the 3rd button as discussed that gives the ability to cycle a postbox between the sortable areas.

I'm not sure which Dashicon would be appropriate for this, but the closest to somehow represent a full move without being a single arrow (just to keep it different from the already 3 existing arrows there) was the Randomize. Not perfect but at least it's different 😅.

Input from the design team would be greatly appreciated if we could use a different icon or if we could even quickly come up with something to implement extra for this :-).

I will be checking tomorrow for the final part which is to support a11y.speak() as well and then we can go for a full final review I believe!

@xkon
10 months ago

#39 @xkon
10 months ago

39074.7.diff also adds a11y.speak() for some of the actions.

To recap what this patch is introducing for an easier review:

  • Introduces 3 new buttons on postboxes. Two of them will move the postboxes within the same group and the third will cycle the postbox through all other groups always on position 1.
  • Changes the HTML output of the buttons to match the DOM.
  • Creates new handle_order, handle_move, enable_disable_order_buttons callbacks in postbox.js with the necessary code for each case.
  • Modifies the wp_ajax_meta_box_order() to return with a wp_send_json_success() and adds a11y.speak() on the save_order ajax as The postboxes order has been saved..
  • Adds a11y.speak() on the handle_order to identify if the current postbox is already first/last on the list as The postbox is already on the first position. & The postbox is already on the last position..

--

Visual preview is the same as 39074.6_preview.gif.

We can always extend & adjust the a11y.speak() messages on future iterations to be more precise regarding the position within the groups as well as add a message for the save_state (this keeps the open/closed as well as the Screen Options list).

Do tell me if I missed anything or if any further adjustments are needed!

#40 @karmatosed
10 months ago

Just going to ask a few questions here as to what the purpose is of doing this.

  • Are these to move or just click up/down? For example, a dragging icon should look different.
  • What is the purpose of adding a mouse click when the idea was re-ordering by keyboard? I'm trying to track down where this has grown a bit.

I would love us to avoid adding so many buttons as this is suddenly a very complicated interface. Perhaps we can look at how the editor implements reordering as a pattern to use, over create another one? Personally, I am not that keen on showing this on every single element as I see in screenshots. Could it for example just be shown on interacting? Similarly, there seem to be some use of accordion arrows for a different purpose to move up and down.

For now, I'd love us to consider the principles we are doing here over just add so let's keep considering that. For now, keeping design feedback label on as it would need some iterations before committing.

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


10 months ago

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


10 months ago

#43 @xkon
10 months ago

Hey @karmatosed, thanks for the feedback and sorry for the late reply here I totally missed the notification :-/ .

Are these to move or just click up/down? For example, a dragging icon should look different.

The first of the 3 buttons is allowing the change between the Sortable areas ( so each column/group per page).

There is no "dragging" icon because dragging is already done by the general Header area as it was done up to now also, this hasn't changed.

What is the purpose of adding a mouse click when the idea was re-ordering by keyboard? I'm trying to track down where this has grown a bit.

I'm not sure I understand the question fully, but essentially we need the buttons to be able to "tab" on these actionable elements and use space/enter to use them, similar to Gutenberg you can use either your mouse on the arrows or drag or your keyboard only as well.

--

I do understand the need for visual simplicity as well in the UI and I'll work on an extra iteration to show/hide the extra buttons while hovering over each postbox to clean up the UI. This would make it similar to how Gutenberg handles its own sorting actions at the moment.

Could you please also give a pointer regarding the move from area to area button? Not sure what icon to use there and the "randomize" icon doesn't seem a perfect fit but I was trying to avoid yet another arrow 😅.

I'll follow up asap with a fresh patch with a show/hide functionality.

#44 @karmatosed
10 months ago

I do understand the need for visual simplicity as well in the UI and I'll work on an extra iteration to show/hide the extra buttons while hovering over each postbox to clean up the UI. This would make it similar to how Gutenberg handles its own sorting actions at the moment.

Thank you for understanding that. I really think if they aren't always on this will help a great deal in actually not being overwhelming as an interface. Could I find a bit more about what that icon represents? Is it to 'move' and drag because then I'd probably go with what is used already in the new editor:

http://cldup.com/tcv446XFGm.png

#45 @xkon
10 months ago

That button "was" used to move through all different areas (i.e. move a postbox between the 4 columns that Dashboard provides for postboxes) as a single-click/keyboard action, not as a dragging handler.

But! I'm already re-writing the whole logic now to only use the Up/Down buttons instead that will also automatically cycle the postbox through all the sortable areas as well automatically so this button will be removed on the next patch and this would make the UI even more simple also.

This was our original discussion with @afercia as well as mentioned on a previous comment here but I was iterating on 'easier' solutions as the first patch in case we could get it in faster. Since we reached this point we might as well provide a finished all-round solution instead :-).

I'll be uploading a fresh patch & preview within the day!

@xkon
10 months ago

#46 @xkon
10 months ago

39074.8.diff adjusts the code and now the postboxes will also move between each sortable area with the same Up/Down buttons. It also shows/hides the additional order buttons on hover/tab to keep the UI clean according to the previous discussion with @karmatosed .

@afercia could you take a look at the latest patch also please if there's time, it includes all of your previous feedback as well for a11y speak and ajax changes :-)?

Preview at 39074.8_preview.gif

#47 @karmatosed
10 months ago

  • Keywords needs-design-feedback removed

From a design view, if the gif is right and they only show on hover, let's remove the keyword to try and get under the wire before beta 1 in a few hours. Thanks for doing this @xkon and all the rapid patching.

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


10 months ago

#49 @afercia
10 months ago

Thanks @xkon for the updated patch! Looking at 39074.8_preview.gif, the ability to move the meta boxes through the various "groups" is really interesting.

A few things I noticed:

1
The buttons appear only on hover / focus.
Specifically:

  • on mousenter: buttons appear
  • on mouseleave: buttons disappear
  • on focus: buttons appear and stay visible when tabbing away

Regardless, things that appear and disappear on the screen are generally not so ideal for accessibility. I do realize the intent to keep the UI "clean" but I think we should find a different mechanism and maybe discuss this in the next meeting and have some design feedback.

2
On the Dashboard, on a medium-sized screen where there are just two columns, the visual feedback is a bit confusing, e.g.:

  • when moving down, the box is actually moved to postbox-container-3 and then to postbox-container-4
  • as these groups are laid out in the second column, nothing seems to happen visually
  • same when moving up: when the box is at the last position, the first and second click seem to do nothing (even if the buttons get actually moved)

Can't think of a way to solve this off the top of my head, we should find some way to make the visual feedback reliable.

3
All the buttons should be moved after the heading. The visual order needs to match the DOM order, see comment:31

4
The screen-reader-text of the buttons should be simplified. While screen reader users would benefit from the current, detailed, text e.g.:
Order Activity panel higher
Order Activity panel lower
Other users would need a simpler text. Speech recognition software users, for example, will see just Up and Down arrows. The control name isn't exposed visually, which is a problem, but I guess the most logic command to voice would be just "Move Up" and "Move Down". Having multiple controls named "Move Up" and "Move Down" would also be slightly annoying because the speech recognition software would show numbers overlaid on the buttons to allow users to choose one of them. That's what we have though :) Maybe something to discuss in the next meeting.

5
The speak() messages use the term "postbox". Users aren't supposed to know what a postbox is.
Both in the dashboard and in the Classic Editor pages, the inline Help refers to "box/boxes" e.g. you can reposition all the other boxes .... I'd just use the term "box".

6
I'd try to reduce the amount of else if used in the patch. A simple if and returning when necessary could make the code simpler and more readable.

7
The keyup event on the body is a bit too invasive maybe.

#50 @audrasjb
10 months ago

  • Milestone changed from 5.4 to Future Release

Hi,

With 5.4 Beta 3 approaching and the Beta period reserved for bugs introduced during the cycle, this is being moved to Future Release. If any maintainer or committer feels this should be included or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

#51 @audrasjb
10 months ago

  • Milestone changed from Future Release to 5.5

Moving it "back" to 5.5 instead of Future Release ;-)

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


8 months ago

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 audrasjb. View the logs.


6 months ago

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


6 months ago

#56 @afercia
6 months ago

  • Owner changed from xkon to afercia

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


6 months ago

#58 @apedog
5 months ago

Perhaps the metabox being moved should have a color change and then fade out. Much like post meta / custom fields box changes to yellow and then fades back to white on update (pink on delete).
This seems less of a problem in the keyboard navigation gif - where the moved metabox keeps the blue focus outline.
But the mouse-click version where the metabox moves instantly while the mouse pointer stays fixed might be confusing.

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


5 months ago

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


5 months ago

#61 @afercia
5 months ago

Quick update: during latest accessibility team meeting, the team agreed to make the "move" buttons always visible.

@afercia
5 months ago

#62 @afercia
5 months ago

  • Keywords needs-dev-note added

39074.9.diff builds on the previous patches and makes the "move" buttons always visible.

It also fixes the mismatch between visual order and DOM order of the elements within the boxes "header". The order is now:

  1. title
  2. ("Configure" link for the few dashboard widgets that provide configuration)
  3. move up
  4. move down
  5. toggle

For the "header" styling, it introduces a new element wrapper and makes use of CSS flexbox so this change will need a quick dev note to inform plugin authors, in case they're adding things to the boxes header.

The patch can be tested:

  • on the Dashboard page: reminder that there are always 4 sortables areas which are laid out depending on the viewport width (zoom out to see them all)
  • on the Classic Editor post edit page: there are 3 sortables areas there

@afercia
5 months ago

Example of the new buttons on the Dashboard

@afercia
5 months ago

#63 @afercia
5 months ago

39074.10.diff removes the postBoxL10n object entirely and uses wp-i18n set_translsations() instead.

The patch will need to be coordinated with the i18n changes from #49288 which provides alternative text for "Drag boxes here" when all the sortable areas are empty.

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


5 months ago

@afercia
5 months ago

#65 @afercia
5 months ago

  • Keywords commit added

39074.11.diff refreshes the patch against latest trunk.

#66 @afercia
5 months ago

During latest accessibility team bug-scrub on Slack ran yesterday it was agreed to always show the reorder buttons as there's consensus to consider appearing and disappearing elements to add to clutter more than permanently visible elements.

The team agreed to commit without further design feedback.

Minor tweaks can always be implemented later during the Beta phase, if necessary.

#67 @afercia
5 months ago

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

In 48373:

Accessibility: Allow post boxes on the Dashboard and Classic Editor pages to be reordered by using the keyboard.

So far, it has been possible to rearrange into a new order the post boxes (also known as "widgets" on the Dashboard and "meta boxes" on the Edit post page) only by using a pointing device, for example a mouse.

This change adds new controls and functionality to allow the boxes to be rearranged also with the keyboard. Additionally, audible messages are sent to the admin ARIA live region to notify screen reader users of the reorder action result.

Props joedolson, anevins, antpb, audrasjb, xkon, MarcoZ, karmatosed, afercia.
Fixes #39074.

#68 @afercia
5 months ago

In the block editor page, when there are meta boxes added by plugins at the bottom of the page, I'm seeing a small defect. Actually, the advanced-sortables area is in the DOM but it's hidden. See also #46964 of other problems caused by this.

The JS should be adjusted to take this into consideration. On it.

@afercia
5 months ago

#69 @afercia
5 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

39074.12.diff does a few things:

  • targets only the visible "sortables" areas, as in the block editor one of them is hidden
  • takes into account that in the block editor there may be just one post box in the meta boxes area and hides the order buttons in that case
  • makes the order buttons slightly bigger in the block editor, to match the handlediv toggle button size

To test in the block editor meta boxes area:

  • install and activate Advanced Custom Fields
  • create a field group and set it to be displayed for posts
  • install another plugin that adds a meta box, e.g. Yoast SEO
  • go to the block editor
  • see two meta boxes are now displayed at the bottom of the page

#70 @afercia
5 months ago

Note for the dev-note:

This change will need to make sure plugins that alter the post boxes "header" are aware of the change and adjust their code accordingly.

For example, Advanced Custom Fields adds a "Edit field group" link in the post box header.

Interesting to note:
in the Classic Editor, Advanced Custom Fields adds one more "sortables" area after the post title:

<div id="acf_after_title-sortables" class="meta-box-sortables ui-sortable">

Thus, it's actually possible to move the boxes before the post title. Not sure ACF should be allowed to do that, but this is the expected behavior, based on the available "sortables" areas.

Luckily, this additional "sortables" area is hidden in the block editor so it's ignored by the JS that handles the order buttons.

@afercia
5 months ago

Boxes moved to the ACF sortables area before the post title

#71 @afercia
5 months ago

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

In 48460:

Accessibility: Improve reordering of the post boxes in the block editor meta boxes area.

Follow-up to [48373].

  • ignores hidden "sortables" areas
  • hides the reorder buttons when there's only one post box
  • makes the reorder buttons slightly bigger to match the side of the toggle button

Fixes #39074.

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


5 months ago

#73 @azaozz
5 months ago

  • Focuses accessibility administration removed
  • Keywords needs-patch needs-design added; has-patch commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Thinking this needs a bit more to get it "just right" :)

The new Up/Down arrows look non-centered, and (perhaps) too far apart for the available space there. Also the circular outlines don't look good, are "off".

Another, arguably bigger, problem is having two "down" arrows next to each other. Kind of confusing at first look. Perhaps the visual difference can be larger, for example color, or border, or...

#74 @azaozz
5 months ago

  • Component changed from Editor to Administration

#75 @azaozz
5 months ago

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

In 48465:

Administration: Attempt to even-out the new Up/Down arrows in metabox headings and make them look a bit better. Also group them a little closer together in an attempt to reduce confusion of having two down arrows next to one another. Move the focus outline to the button instead of only the icon.

Fixes #39074.

#76 @azaozz
5 months ago

Still not great but ... better? :)

#77 @afercia
5 months ago

  • Focuses accessibility added

#78 @afercia
5 months ago

@azaozz thanks for the improvements to the buttons alignment :)

Regarding the "target size", I'd just like to note that assuming a clickable area size on desktop is only important for touch is a wrong assumption. See also the related discussion on Slack.

Users with motor impairments, tremors, etc. need a large target size. The larger, the better. Reducing it on purpose isn’t the best way forward to guarantee all users can use those buttons.

There's also a specific WCAG requirement about the target size, although it's for level AAA. WordPress aims for level AA but it's worth mentioning anyways.

See before and after in the screenshots below.

@afercia
5 months ago

Clickable area before: 36 by 36 pixels and consistent for all buttons

@afercia
5 months ago

Clickable area after: smaller and inconsistent

#79 follow-up: @azaozz
4 months ago

  • Keywords needs-testing added
  • Priority changed from normal to highest omg bbq
  • Resolution fixed deleted
  • Severity changed from normal to blocker
  • Status changed from closed to reopened

Looks like the related #49288 will have to be reverted as it needlessly breaks backwards compatibility and can potentially impact a very large number of plugins and sites.

Not sure if the changes committed here can exist independently from the changes committed at #49288. For that reason marking this for a revert in 5.5. It will likely need fixing and improving the code and adding in 5.6.

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


4 months ago

#81 in reply to: ↑ 79 ; follow-up: @afercia
4 months ago

I'm not sure there's a good reason to revert this change.

Replying to azaozz:

Not sure if the changes committed here can exist independently from the changes committed at #49288. For that reason marking this for a revert in 5.5. It will likely need fixing and improving the code and adding in 5.6.

Technically, this change is independent from the one in #49288 / [48340]. I think there are just two very minor conflicts to address when reverting [48340] and maybe a bottom margin to keep in the CSS.

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


4 months ago

#83 in reply to: ↑ 81 ; follow-up: @azaozz
4 months ago

Replying to afercia:

Technically, this change is independent from the one in #49288 / [48340]. I think there are just two very minor conflicts to address...

That's great. Could you please patch this.

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

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


4 months ago

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


4 months ago

#86 in reply to: ↑ 83 @afercia
4 months ago

Replying to azaozz:

That's great. Could you please patch this.

There's now a patch on #49288 to address the compatibility concerns after [48340], as discussed on that ticket. If that patch gets committed, I'm not sure there's anything else to address on this ticket.

#87 @afercia
4 months ago

  • Keywords needs-patch needs-design needs-testing removed
  • Priority changed from highest omg bbq to normal
  • Resolution set to fixed
  • Severity changed from blocker to normal
  • Status changed from reopened to closed

With the backwards compatibility concerns for #49288 addressed in [48717] and [48718] I'm not sure there's anything else to do on this ticket. I'm going to close it as fixed. Please do reopen it if I'm missing something.

Re: the dev note:
it should be published soon :) /Cc @justinahinon

As mentioned in comment:70, plugins that alter the post boxes / meta boxes "header" need to be aware of the change and adjust their code accordingly.

As an example: in the WooCommerce "Edit order" pages, some CSS from WooCommerce hides the heading and the handlediv button for some meta boxes by using display: none, see screenshot below. This makes the "reoder buttons" be displayed on the left instead of on the right. No functionality is broken and the meta box is sortable as expected, as it lives within an element with the CSS class meta-box-sortables. This CSS class is, and it has always been, the target for jQuery UI Sortable.

If plugins want to customize the core meta boxes this way, that's fine but they should also be ready to adjust their customizations when necessary.

@afercia
4 months ago

WooCommerce Edit order page: the "Order data" customized meta box

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


4 months ago

#90 @johnstonphilip
4 months ago

This change broke some of my years-older projects that are still out in the wild.

I was running some jquery to load the contents of metaboxes using ajax when they are opened. Because there's a new container now, it required another parent call to get to the top of the metabox.

Old code which broke because of this change:

$( document ).on( 'click', '.postbox .handlediv, .postbox .hndle', function( event ){
   var content_placeholder = $(this).parent().find( '.my_metabox_ajax_placeholder' );
   // Did ajax call to replace the placeholder here.
}

Updated code which fixed it due to the new wrapping elements added here:

$( document ).on( 'click', '.postbox .handlediv, .postbox .hndle', function( event ){
   var content_placeholder = $(this).parent().parent().parent().find( '.my_metabox_ajax_placeholder' );
   // Did ajax call to replace the placeholder here.
}

Take note of the parent().parent().parent() calls.

Leaving this note so it might help anyone else with a similar issue.

Last edited 4 months ago by johnstonphilip (previous) (diff)
Note: See TracTickets for help on using tickets.