WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 days ago

#39074 assigned defect (bug)

No method to move meta boxes using keyboard

Reported by: joedolson Owned by: xkon
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Editor Keywords: wpcampus-report has-patch needs-design-feedback has-screenshots
Focuses: ui, accessibility, administration Cc:
PR Number:

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 (13)

4A1B714B-6886-470C-BD7C-313BA317BDE7.png (76.9 KB) - added by antpb 5 months ago.
An example where this has accessibility difficulties
39074.diff (3.7 KB) - added by xkon 10 days ago.
39074_preview.gif (2.4 MB) - added by xkon 10 days ago.
39074.2.diff (4.6 KB) - added by xkon 10 days ago.
39074.2_preview.jpg (49.9 KB) - added by xkon 10 days ago.
e023d824fba3497e5f81cd1f5ed80441.gif (916.5 KB) - added by audrasjb 9 days ago.
Testing xkon’s patch
39074.3.diff (5.5 KB) - added by xkon 8 days ago.
39074.3_preview.gif (620.3 KB) - added by xkon 8 days ago.
advanced meta-box-sortable with height 0.png (202.5 KB) - added by afercia 4 days ago.
39074.4.diff (7.6 KB) - added by xkon 4 days ago.
39074.4_preview.gif (348.8 KB) - added by xkon 4 days ago.
39074.5.diff (8.2 KB) - added by xkon 3 days ago.
39074.5_preview.gif (2.7 MB) - added by xkon 3 days ago.

Change History (50)

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


3 years ago

#2 @afercia
3 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.


2 years ago

#4 @afercia
8 months ago

Related: #47135.

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


5 months ago

#6 @anevins
5 months ago

  • Keywords wpcampus-report added; needs-patch removed

Added keyword

#7 @antpb
5 months ago

#47135 was marked as a duplicate.

#8 @antpb
5 months ago

  • Description modified (diff)

#9 @antpb
5 months ago

  • Milestone changed from Future Release to 5.3

@antpb
5 months ago

An example where this has accessibility difficulties

#10 @afercia
5 months ago

Full detailed report available at #47135.

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


5 months ago

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


5 months ago

#13 @audrasjb
5 months ago

  • Keywords needs-design added

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


4 months ago

#15 @anevins
4 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
4 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
4 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
4 months ago

  • Milestone changed from 5.3 to Future Release

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


3 months ago

#20 @afercia
3 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.


10 days ago

@xkon
10 days ago

@xkon
10 days ago

#22 @xkon
10 days 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
10 days ago

@xkon
10 days ago

#23 @xkon
10 days 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
9 days ago

This looks good to me from a screen reader perspective.

@audrasjb
9 days ago

Testing xkon’s patch

#25 @audrasjb
9 days 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.


9 days ago

@xkon
8 days ago

@xkon
8 days ago

#27 @xkon
8 days 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 8 days ago by xkon (previous) (diff)

#28 @audrasjb
8 days 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.


6 days ago

#30 @audrasjb
6 days ago

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

#31 @afercia
4 days 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
4 days 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
4 days 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
4 days ago

@xkon
4 days ago

#34 @xkon
3 days 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.


3 days ago

@xkon
3 days ago

@xkon
3 days ago

#36 @xkon
3 days 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
3 days ago

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

Note: See TracTickets for help on using tickets.