Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#31090 closed defect (bug) (fixed)

Menus manage locations form accessibility improvements

Reported by: afercia's profile afercia Owned by: jorbin's profile jorbin
Milestone: 4.2 Priority: normal
Severity: normal Version: 3.6
Component: Menus Keywords: has-patch ui-feedback
Focuses: ui, accessibility Cc:

Description

In nav-menus.php -> action=locations screen, the form for managing locations has a select without a proper associated label. In the proposed patch, a few small improvements:

  • labels for selects
  • better context for the "Edit" link, with same technique used e.g. in the Posts "Publish" postbox
  • small CSS refinements
  • fixed duplicated ID id="menu-locations-row" when more than one menu location, no need to have an ID here unless I'm missing something

Attachments (1)

31090.patch (2.5 KB) - added by afercia 10 years ago.

Download all attachments as: .zip

Change History (9)

@afercia
10 years ago

#1 @afercia
10 years ago

  • Keywords has-patch added

#2 @jorbin
10 years ago

  • Keywords ui-feedback added
  • Milestone changed from Awaiting Review to 4.2
  • Version changed from 4.1 to 3.6

It looks like this issue has existed since at least when we switched to the tabbed interface.

This will need some testing, but should go in 4.2. I also think some designers should sign off on the proposed UI tweaks.

related: #23770 [23810]

#3 @melchoyce
10 years ago

Can we get before/after screenshots?

#4 @jorbin
10 years ago

before:https://cldup.com/XjsjeHtZOx-3000x3000.png

After: https://cldup.com/ZKwBnwoVnS-3000x3000.png

I think it's a good move to better align the locations.

#5 @melchoyce
10 years ago

Definitely a lot better. Looks great.

#6 @jorbin
10 years ago

The one part of this change I'm not sure about is

<?php _ex( 'Edit', 'menu' ); ?>

moving to be

<span aria-hidden="true"><?php _ex( 'Edit', 'menu' ); ?></span><span class="screen-reader-text"><?php _e( 'Edit selected menu' ); ?></span>

It's not hidden now, so I'm not sure the aria-hidden=true needs to be there. We only display the locations-edit-menu-link span when we have a menu item, so I'm not sure it doesn't need the aria-hidden. My understanding is that Indicates that the element and all of its descendants are not visible or perceivable to any user as implemented by the author and in this case it's not actually hidden.

#7 @afercia
10 years ago

@melchoyce

Definitely a lot better. Looks great.

thanks, such a small change :)

@jorbin
yup can be confusing at first sight, this technique is already used in the admin, for example in the "Publish" postbox:

<a href="#post_status" class="edit-post-status hide-if-no-js"> 
<span aria-hidden="true">Edit</span> <span class="screen-reader-text">Edit status</span>
</a>

this way, screen readers will read out "Edit status" and will ignore "Edit" which, alone, doesn't give enough context to screen reader users: Edit... what? Sighted users have enough information about the link purpose thanks to the visual context.

Back to the locations-edit-menu-link specific case:

  • for screen reader users "Edit" is always hidden, regardless the link is hidden or not
  • when the link gets visible:
    • screen reader will read out just the "Edit selected menu" part
    • sighted users will see just "Edit"

http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden
"Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies."

It's also a way to have a fully translatable, clean, string without mixing it with HTML. Currently used in Twenty Fifteen too.

Last edited 10 years ago by afercia (previous) (diff)

#8 @jorbin
10 years ago

  • Owner set to jorbin
  • Resolution set to fixed
  • Status changed from new to closed

In 31272:

Improve accessibility of nav menu locations form.

A couple of small tweaks to the nav menu locations form that make it friendlier to assistive technology. These include:

  • labels for selects
  • better context for the "Edit" link. We hide "edit" from screen readers and instead give them a phrase with context since they may not be able to take advantage of the visual context

Additionally, there are some minor css tweaks to improve the visual alignment of the rows.
We also remove duplicate IDs and use classes instead.

Props afercia.
fixes #31090.

Note: See TracTickets for help on using tickets.