Opened 8 years ago
Last modified 7 weeks ago
#33064 accepted enhancement
Customizer: form inputs need a way to have hidden labels
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.3 | Priority: | normal |
Severity: | normal | Version: | 4.2 |
Component: | Customize | Keywords: | has-patch needs-refresh needs-docs |
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)
Change History (23)
This ticket was mentioned in Slack in #core-customize by valendesigns. View the logs.
8 years ago
#3
@
8 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
#5
@
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.
#6
follow-up:
↓ 7
@
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
@
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
@
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
@
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?
#11
@
8 years ago
Thinking jQuery UI uses ui-helper-hidden-accessible
so maybe something like $label_hidden_accessible
?
#12
@
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
.
This ticket was mentioned in Slack in #core by ocean90. View the logs.
8 years ago
#15
@
8 years ago
- Milestone changed from 4.4 to Future Release
- Type changed from defect (bug) to enhancement
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
7 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
#19
@
2 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 looks like a good candidate for 4.4, though it may need some unit tests.