[wp-trac] [WordPress Trac] #60672: Improve menu toggle accessible name in admin menus

[WordPress Trac]

#60672: Improve menu toggle accessible name in admin menus
-------------------------------------+----------------------------
 Reporter:  joedolson                |       Owner:  joedolson
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  6.6
Component:  Menus                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-refresh  |     Focuses:  accessibility
-------------------------------------+----------------------------
Changes (by afercia):

 * keywords:  has-patch needs-testing => has-patch needs-refresh


Comment:

 Thanks for the ping @joedolson. A few observations after testing
 [attachment:"60672.2.diff"]:

 == JS off

 When JavaScript is disabled, the items are supposed to show a different
 UI, with a 'Move up', 'Move down' and an 'Edit' links. The current patch
 alters the 'Edit' following the new patter. I'm not sure that would be
 ideal in this no-js scenario. See attached screenshot.

 == The position indication
 The menu items are placed within an unordered list. However, the list is
 'flat' and doesn't convey semantically the visual nesting. I think this is
 the original reason why the accessibility text that communicates the
 position was added. Users can change the nesting and order of the items.
 Updating on the fly the markup structure of the unordered list to
 semantically reflect the new nesting and order would be very complicated.
 The accessibility text is a remediation and I'd agree it's a little
 verbose but I'm not sure removing it entirely would be ideal. Is there any
 specific feedback from users that removing it is preferable?

 == The new name with 'Edit menu item'
 I'd agree that prepending 'Edit menu item' to the accessible name would
 make the name consistent with the one used in the Customizer. It would
 also add more context for screen reader users. However, I'm not sure that
 would be great for other users, for example speech recognition software
 users. I'm concerned about the [https://www.w3.org/TR/WCAG22/#label-in-
 name Label in Name] principle though. ''Technically'', the name contains
 the text that is presented visually. Practically, that would not work. For
 exammple:

 **Visible text: About The Tests   Page**
 With the old `aria-label="About The Tests. Menu item 2 of 4."` the visible
 text is at the start of the name. There is a chance a voice command issued
 via speech recognition software may work.
 With the new `aria-label="Edit menu item: About The Tests (Page)"` the
 visible text is in the middle of the name. As far as I can tell, this
 won't work with speech recognition software.
 On the other hand, it is true that:
 - The pattern that starts with 'Edit ...' and mismatches the visible text
 is used in other parts of the admin so this is a broader issue.
 - Speech recognition software users do have other means to activate those
 links (e.g. 'Show numbers' or 'Show grid') although these alternative
 methods are less efficient and tedious.

 == Concatenation and escaping
 Example from the patch:
 `esc_attr__( 'Edit menu item: ' . esc_html( $title ) . ' (' . esc_html(
 $menu_item->type_label ) . ')' ),`

 - We should avoid concatenation within translatable strings. `sprintf()`
 and placeholders should be used to provide a fully translatable string.
 - In the example above, the entire string is already escaped with
 `esc_attr__()`. I'm not sure the variables within the string should be
 escaped with `esc_html()`. Of course by using `sprintf()` the escaping
 mechanism would be different.

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