Make WordPress Core

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#37648 closed defect (bug) (invalid)

Bind label to Plugins > Install search input field

Reported by: mercime's profile mercime Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Plugins Keywords: has-patch
Focuses: accessibility, administration Cc:

Description

Add the for and id attributes to the label tag and search input field respectively. The value of those attributes are the same as the value from the wp-admin theme install's label and input fields.

Attachments (1)

37648.patch (1.1 KB) - added by mercime 8 years ago.

Download all attachments as: .zip

Change History (10)

@mercime
8 years ago

#1 @mercime
8 years ago

  • Keywords has-patch added

#2 @swissspidy
8 years ago

  • Component changed from Administration to Plugins
  • Focuses administration added
  • Milestone changed from Awaiting Review to Future Release

#3 @joedolson
8 years ago

Because this field is labeled implicitly, adding the for and id attributes doesn't accomplish anything. However, if the label were changed so it did *not* wrap the input, then the for and id attributes were added, this would improve accessibility for users of voice input software.

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


8 years ago

#6 @joedolson
8 years ago

Although this isn't a patch we'll be able to use, thanks for your contribution! If you have the time to create a patch that changes this to an explicit label, that would be awesome! Thank you for contributing!

#7 @mercime
8 years ago

Because this field is labeled implicitly, adding the for and id attributes doesn't accomplish anything

Hi @joedolson. Re implicit labelling, when I started improving a11y for projects and sites, one of my go-to references is the Mozilla Developer Network site where it states:

A <label> element is bound to its widget with the for attribute. The for attribute references the id attribute of the corresponding widget. A widget can be nested inside its <label> element but even in that case, it is considered best practice to set the for attribute because some assistive technologies do not understand implicit relationships between labels and widgets.

In addition, the WordPress A11y Coding Standards the information given there is that "All form inputs must include an explicitly associated <label> element."

So if the WP a11y team consensus is that adding for attributes for <label>s is useless when widgets are nested, perhaps that should be clarified, as I see at least many instances throughout the WP codebase where for attributes were added to <label>s with widgets nested. Thank you.

(copy pasted most from https://core.trac.wordpress.org/ticket/37649#comment:6 )

#8 @afercia
7 years ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Status changed from new to closed

A widget can be nested inside its <label> element but even in that case, it is considered best practice to set the for attribute because some assistive technologies do not understand implicit relationships between labels and widgets.

This MDN statement sounds a bit arbitrary to me, not so clear who considers that a best practice, and no argumentation or data to support it. Also, seems the HTML example on that same page goes against that statement. See the comment in the example:
<!-- so here, the 'for' attribute is redundant. -->

I'd recommend to stick to what the W3C says:

HTML5 spec:
https://www.w3.org/TR/html5/forms.html#the-label-element

The label element represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element's labeled control, either using the for attribute, or by putting the form control inside the label element itself.

W3C Web Accessibility Tutorials:
https://www.w3.org/WAI/tutorials/forms/labels/

A label and a form control need to be associated with each other either implicitly or explicitly.

Also, I'd recommend to have a look at the following post because the argumentations there are supported by extensive tests, even if they're a bit old (2011):
https://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-form-control-labeling/

... if you want controls to be understandable to AT users label controls using for and id. Do not use the control inside the label method. Do not use a combination of the 2 methods.

The current recommendation in WordPress is to avoid a combination of the two techniques. I guess there are still cases that need to be properly addressed though. And yes, probably the A11y Coding Standards handbook page needs to clarify a bit this issue :) /cc @joedolson

Going to close this ticket. Please consider discussion can continue on closed tickets, and do feel free to re-open it if new information or new data may suggest improvements or better implementations.

#9 @joedolson
7 years ago

I think that the A11y Coding Standards documentation is accurate, but I can see room for clarification. Let's discuss the wording in the next team meeting. What the document actually states is that new or modified code must have explicit labels; which is to say that if a form input is revised, and the original version used implicit labeling, the new version should use explicit labeling instead of implicit.

We'll have to come up with wording that indicates clearly that existing implicit labels should be replaced with explicit.

Note: See TracTickets for help on using tickets.