Make WordPress Core

Opened 8 months ago

Closed 4 months ago

#63970 closed defect (bug) (wontfix)

Disabled .handle-actions button receives keyboard focus

Reported by: alh0319's profile alh0319 Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.5
Component: Administration Keywords: has-patch
Focuses: accessibility Cc:

Description

The dashboard metaboxes have arrow buttons that allow them to be moved up and down with a keyboard. The top-most metabox has a disabled move up button that is not probramatically disabled so it still receives keyboard focus though it is not functional.

Example:

<button type="button" class="handle-order-higher" aria-disabled="true" aria-describedby="dashboard_site_health-handle-order-higher-description"><span class="screen-reader-text">Move up</span><span class="order-higher-indicator" aria-hidden="true"></span></button>

It would be better if the disabled attribute were added to this button or if it had a negative tab index so that it doesn't receive keyboard focus outside of when the focus is already on it (because it was used to move a meta box into the top-most position).

Change History (9)

#1 @alh0319
8 months ago

This button is also present in the classic editor meta boxes.

#2 @yashjawale
8 months ago

Thanks @alh0319 for reporting the bug!
I can reproduce this problem, starting work on a patch to fix this...

This ticket was mentioned in PR #9915 on WordPress/wordpress-develop by @yashjawale.


8 months ago
#3

  • Keywords has-patch added

This PR prevents keyboard focus for dashboard metabox widget arrows which are disabled

Trac ticket: https://core.trac.wordpress.org/ticket/63970

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


8 months ago

#5 @joedolson
8 months ago

  • Version set to 5.5

Only using aria-disabled was intentional at the time. Making the button disabled just introduces other problems, such as a need to move focus when a meta box is moved into an immovable position and causing buttons to disappear when they are not available, rather than just announcing them as disabled.

See: https://core.trac.wordpress.org/ticket/39074#comment:31

Whether something disabled should be totally unavailable or not is a philosophical point: WordPress has generally made the choice that screen readers should be able to perceive disabled fields, rather than hiding them. But this can be re-discussed, certainly.

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


6 months ago

#7 @joedolson
6 months ago

  • Milestone changed from Awaiting Review to 7.0

Related: #50699. Milestoning for 7.0 along with that, to re-address how these are handled.

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


4 months ago

#9 @joedolson
4 months ago

  • Milestone 7.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

On discussion in the #a11y bug scrub, we agreed that this would not be an improvement, and that it's a better experience for the user to not go through unexpected focus changes, as well as having access to all visible controls, which is a more equal experience to what a sighted user has.

Note: See TracTickets for help on using tickets.