WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 7 months ago

#33064 assigned enhancement

Customizer: form inputs need a way to have hidden labels

Reported by: afercia Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.2
Component: Customize Keywords: has-patch
Focuses: ui, accessibility Cc:

Description

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.

Attachments (2)

33064.diff (1.9 KB) - added by umesh.nevase 23 months ago.
added parameter to add_contol function arguements to show or hide screen_reader_text
33064.2.diff (3.8 KB) - added by valendesigns 22 months ago.

Download all attachments as: .zip

Change History (20)

This ticket was mentioned in Slack in #core-customize by valendesigns. View the logs.


2 years ago

#2 @valendesigns
2 years ago

  • Keywords needs-patch added

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

#3 @valendesigns
2 years ago

  • Milestone changed from Awaiting Review to 4.4
  • Owner set to valendesigns
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core by sergey. View the logs.


2 years ago

@umesh.nevase
23 months ago

added parameter to add_contol function arguements to show or hide screen_reader_text

#5 @umesh.nevase
23 months ago

  • Keywords has-patch added; needs-patch removed

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.

#6 follow-up: @valendesigns
22 months ago

@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?

#7 in reply to: ↑ 6 @afercia
22 months ago

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.

#8 @westonruter
22 months ago

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?

#9 @valendesigns
22 months ago

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?

#10 @umesh.nevase
22 months ago

@valendesigns

$screen_reader_label is correct choice, short and descriptive.

Last edited 22 months ago by umesh.nevase (previous) (diff)

#11 @afercia
22 months ago

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

#12 @ocean90
22 months ago

$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.

#13 @wonderboymusic
22 months ago

  • Owner changed from valendesigns to ocean90

This ticket was mentioned in Slack in #core by ocean90. View the logs.


22 months ago

#15 @ocean90
22 months ago

  • Milestone changed from 4.4 to Future Release
  • Type changed from defect (bug) to enhancement

#16 @ocean90
21 months ago

  • Owner ocean90 deleted

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


12 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 months ago

Note: See TracTickets for help on using tickets.