Opened 10 years ago
Closed 10 years ago
#31090 closed defect (bug) (fixed)
Menus manage locations form accessibility improvements
Reported by: | afercia | Owned by: | 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)
Change History (9)
#2
@
10 years ago
- Keywords ui-feedback added
- Milestone changed from Awaiting Review to 4.2
- Version changed from 4.1 to 3.6
#6
@
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
@
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.
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]