Make WordPress Core

Opened 9 years ago

Closed 9 months ago

#33064 closed enhancement (maybelater)

Customizer: form inputs need a way to have hidden labels

Reported by: afercia's profile afercia Owned by: joedolson's profile joedolson
Milestone: Priority: normal
Severity: normal Version: 4.2
Component: Customize Keywords: has-patch needs-docs close
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 (3)

33064.diff (1.9 KB) - added by umesh.nevase 8 years ago.
added parameter to add_contol function arguements to show or hide screen_reader_text
33064.2.diff (3.8 KB) - added by valendesigns 8 years ago.
33064.3.diff (3.3 KB) - added by joedolson 9 months ago.
Refreshed

Download all attachments as: .zip

Change History (28)

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


9 years ago

#2 @valendesigns
9 years ago

  • Keywords needs-patch added

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

#3 @valendesigns
9 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.


8 years ago

@umesh.nevase
8 years ago

added parameter to add_contol function arguements to show or hide screen_reader_text

#5 @umesh.nevase
8 years 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.

@valendesigns
8 years ago

#6 follow-up: @valendesigns
8 years 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
8 years 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
8 years 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
8 years 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
8 years ago

@valendesigns

$screen_reader_label is correct choice, short and descriptive.

Last edited 8 years ago by umesh.nevase (previous) (diff)

#11 @afercia
8 years ago

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

#12 @ocean90
8 years 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
8 years ago

  • Owner changed from valendesigns to ocean90

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


8 years ago

#15 @ocean90
8 years ago

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

#16 @ocean90
8 years ago

  • Owner ocean90 deleted

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


8 years ago

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


7 years ago

#19 @celloexpressions
3 years ago

  • Keywords needs-refresh needs-docs added

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.

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


11 months ago

#21 @joedolson
11 months ago

  • Milestone changed from Future Release to 6.3
  • Owner set to joedolson
  • Status changed from assigned to accepted

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


9 months ago

#23 @joedolson
9 months ago

  • Keywords close added; needs-refresh removed

The add new menu flow was updated for WordPress 4.9, and has had a visible label since then. There are no other core controls that have hidden labels in the customizer as far as I can tell.

Given that development focus is heavily moved to the full site editor and this change would now have no impact on WordPress core, I don't think it makes a lot of sense to implement it.

I'm suggesting that we close this; but I'm open to other suggestions if other contributors think that extenders will still make use of this.

@joedolson
9 months ago

Refreshed

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


9 months ago

#25 @kirasong
9 months ago

  • Milestone 6.3 deleted
  • Resolution set to maybelater
  • Status changed from accepted to closed

While triaging the 6.3 milestone for enhancements, I found this ticket.

Since @joedolson recommends closing the ticket, I'm going to go ahead and do so.

If anyone finds this ticket later and would find the change useful for enhancing accessibility, please feel free to leave a comment here and reopen!

Note: See TracTickets for help on using tickets.