Customizer: form inputs need a way to have hidden labels

[afercia]

Splitting this out from #32726.

For accessibility, all form controls that require user input must be associated with a label element (see Guideline 3.3.2 ​http://www.w3.org/TR/2008/REC-WCAG20-20081211/#minimize-error-cues )

In some places, the Customizer UI visual design doesn't provide a visible label. For example, the "New menu name" field.

Currently, in order to try to find a balance between visual design, functionality and accessibility, WordPress is making large use of hidden labels across all the admin. I'm not completely sure hidden labels would meet WCAG Level A, by the way the Customizer currently lacks the ability to add a hidden label to form controls, see WP_Customize_Control::render_content().

As noted in #32726 this sounds like something that affects more than just one input field and maybe we should consider to improve the default Customizer controls output adding an easy way to have hidden label text.

[valendesigns]

This looks like a good candidate for 4.4, though it may need some unit tests.

[umesh.nevase]

added parameter to add_contol function arguements to show or hide screen_reader_text

[umesh.nevase]

Hi @valendesigns,
I could not find any other input field other than "New menu name" without label. I've added simple solution to add label with 'screen_reade_text' class in attached patch 33064.diff.

[valendesigns]

@afercia Other than the new_menu_name control, are there other controls in the Customizer than are missing a label that you want this ticket to address?

@westonruter or anyone else, do you have objections to the approach in 33064.2.diff​ or the $label_hidden class property I created?

[afercia]

Replying to valendesigns:

@afercia Other than the new_menu_name control, are there other controls in the Customizer than are missing a label that you want this ticket to address?

Couldn't find any other among the "default" ones.

[westonruter]

I think 33064.2.diff​ looks good. The only thing I could thing of is to maybe rename $label_hidden to something like $label_is_screen_reader_text (bad name), since the label isn't actually “hidden” from users of assistive technologies.

There are other instances of the customize-control-title class being used in that file, including both other controls in PHP as well as JS-templated controls. Should the $label_hidden property be honored for them as well?

[valendesigns]

Related #33085

I think that there is some overlap with this issue and #33085 and that this issue would be best to go first since it has markup changes that #33085 will need to take into consideration. I'll work up a new patch that uses a more descriptive property and updates the JS template controls. However, $label_is_screen_reader_text seems overly verbose and $screen_reader_text doesn't say what is being displayed only to screen readers so I guess the former is the correct choice if it's between the two. There is likely many other choices but what about $screen_reader_label? Anyone else have suggestions, preferably shorter ones that describe the intended outcome?

[umesh.nevase]

@valendesigns

$screen_reader_label is short and descriptive.

[afercia]

Thinking jQuery UI uses ui-helper-hidden-accessible so maybe something like $label_hidden_accessible ?

[ocean90]

$label_is_screen_reader_text looks good too me, because it's a boolean value and_is_ makes this clear.

Another idea is the prefix $use, for example $use_label_as_screen_reader_text.

[celloexpressions]

Unfortunately this got stuck on picking a name and lost momentum. Of the options above, $use_label_as_screen_reader_text seems the clearest to me. Noting that this variable name becomes part of the public customize API and needs to be documented in the handbook as well, here: ​https://developer.wordpress.org/themes/customize-api/customizer-objects/#controls

33064.2.diff​ looks good to me - can someone update the name of the variable and confirm it still applies against trunk? If so, then this is ready to go.