[wp-trac] [WordPress Trac] #40678: Editing menus in WP admin for blind people

[WordPress Trac]

#40678: Editing menus in WP admin for blind people
--------------------------+----------------------------
 Reporter:  juliemoynat   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.0
Component:  Menus         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  accessibility
--------------------------+----------------------------

Comment (by afercia):

 @audrasjb @juliemoynat thanks for working on this :)

 > what is the process for partial fixes? Is it okay to commit some fixes
 but let the ticket open?

 One thing I've learned contributing to WordPress is that it's better to
 keep patches small :) Trying to solve everything in one patch can
 sometimes make things harder. I'd suggest to keep things simple and split
 remaining issues in separate tickets.

 A few suggestions:
 - I wouldn't touch the accordions, there's already a ticket for that:
 #42002
 - I know the wording `Press return or enter to open this section` is
 already used in core so it seems natural to reuse it, however it's not
 that ideal. Only a few keyboard layouts have different Enter and Return
 keys, and in any case it's a bit redundant. Users just need to know they
 have to activate the control. Also, I'd use `aria-expanded` when possible.
 - “Edit menus” and “Manage locations” are not real tabs: they look like
 tabs but actually they're just links. It's more a sub-navigation menu and
 it should be marked up as such. However, there are other places in core
 where the same pattern is used, for example in the "About" pages and on
 multisite, I think the best option would be trying to address this issue
 globally across the admin. It's also confusing because many plugins use
 the same visual pattern for tabs that are real tabs. I'd suggest to
 discuss this issue in the next accessibility meeting, and also evaluate
 the usage of `aria-current`.
 - Instead, "Most recent", "View all", and "Search", are real tabs and they
 should use the ARIA tabs pattern. To my knowledge, the only implementation
 of aria tabs in core so far it's in the embed "sharing dialog" in the
 front-end. It would be great to have some new functions able to output a
 proper ARIA tabbed interface. I'd tend to think this should be addressed
 separately from this ticket.
 - headings: they're great and they're also used by screen reader users to
 navigate content. I'd consider to make them visible (and shorter). Also
 for consistency with the widget screen, where there's an "Available
 Widgets" heading:
 [[Image(https://cldup.com/c9UJDILJEo.png)]]
 - about the heading on the right column, we can't use the words "Menu
 Settings" because there's already a "Menu Settings" at the bottom of the
 screen. I'd rather consider to move the existing "Menu Structure" before
 the right column, if that makes sense.
 - the text added to the "Add to Menu" buttons is a bit too long. I'm not
 so sure it should be added there in the first place:
 [[Image(https://cldup.com/uJoEmYUyyA.png)]]
 - the JavaScript part on the "Edit" links is a bit complicated. Please
 consider this whole screen has a "no-JS' fallback and when JavaScript is
 disabled, the links look this way:
 [[Image(https://cldup.com/vVQoc-Ahz7.png)]]
 - when JS is on, the aria-label gets populated with information about the
 menu item position, for example: `{child item name}. Sub item number 2
 under {parent item name}.` I guess this part was implemented some years
 ago. The intent is good but I agree it doesn't tell users what that link
 does. I'd try to prepend `Edit menu item:` to the aria label value. These
 links should also use `aria-expanded` to communicate the state of the
 expandable panel. I wouldn't use “Press return or enter to open this
 section” at all.

 Sorry for the wall of text :) In a few words, I'd suggest to split the JS
 part in a separate ticket and discuss the tabs/non-tabs in the next
 meeting.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40678#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform