Customizer: Accessibility: form controls need a label with text

[designsimply]

/hat tip @afercia for the original report at ​https://github.com/voldemortensen/menu-customizer/issues/97

Found the edit menu name in Customizer Menus has a label without any text, haven't checked all form controls though.

Currently:

<label>
<input class="menu-name-field live-update-section-title" value="Testing Menu Customizer" data-customize-setting-link="nav_menus[236][name]" type="text">
</label>

To my understanding, this would require something in in WP_Customize_Control to add CSS classes to the label text (the inner span, not the label itself) in order to use screen-reader-text and hide the label text.

[designsimply]

Screenshot for reference:

^{Tested with WordPress 4.3-alpha-32775 and Menu Customizer plugin 0.6 (cef7fbc).}

[afercia]

First pass.

• adds a new property $label_text_class to set CSS classes on the labels <span>
• adds missing label text in WP_Customize_Nav_Menu_Name_Control::content_template()

[celloexpressions]

I'm not a fan of adding a label_text_class property to the main core control. But, I think it could be useful to add something along the lines of hidden_label, that allows devs to more easily include a label but not show it, including making it accessible for screen readers automatically in the process. Looking at the patch, but not the surrounding code, it looks like the change to the new menu control covers the issue for Menus, so we wouldn't need the change to the main control, but I haven't looked closely.

[afercia]

Would be happy to see any improvements to the patch, I'm not so familiar with the Customizer and implemented just a basic way to get the job done :) Please feel free to change it whatever way you think it's best, as long as form fields have a label.

[celloexpressions]

I think the best approach here is to add the label via the API and then hide it manually with CSS in customize-nav-menus.css. Rather than changing the API.

[obenland]

Replying to celloexpressions:

I think the best approach here is to add the label via the API and then hide it manually with CSS in customize-nav-menus.css. Rather than changing the API.

Can you write a patch for that? It would be good to keep moving this ticket forward.

[obenland]

@celloexpressions, could you make this part of your weekend todo list?

[celloexpressions]

I can do a patch for this in time for beta 3, should be pretty straightforward.

[celloexpressions]

Add a label to the menu name field for screen readers.

[celloexpressions]

I really don't like that we have a custom control for a text input (or custom controls for checkboxes and selects), but that's apparently how it is right now, so 32726.2.diff​ should work. #30738 would've probably avoided the need for those custom controls with a bit of creativity in the implementation on the menus side.

[afercia]

Tested the patch, works nicely. Noticed also the New menu name would need a label text, currently it has just a label without text. Is there already a ticket for that or maybe can be handled here?

[obenland]

Replying to afercia:

Tested the patch, works nicely. Noticed also the New menu name would need a label text, currently it has just a label without text. Is there already a ticket for that or maybe can be handled here?

Feel free to add to celloexpressions' patch.

[afercia]

Adding a label for the New menu name would be pretty easy but then the label text will be visible. Maybe we should consider to improve the default output adding an optional way to have hidden label text. A temporary fix would be some redundant CSS rule :)

[obenland]

It sounds like something that affects more than just the new menu input field. Let's get the existing patch in and create a new ticket for that for 4.4.

[obenland]

In 33346:

Customizer: Add label for menu names when editing a menu.

Props celloexpressions.
Fixes #32726.