Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#37649 closed defect (bug) (invalid)

Bind `label`s to form controls in Tools > Export screen

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


Some input fields and select form controls are not bound to respective labels on this screen. Attached patch fixes the issue for accessibility.

Attachments (1)

37649.patch (3.5 KB) - added by mercime 8 years ago.

Download all attachments as: .zip

Change History (8)

8 years ago

#1 @mercime
8 years ago

  • Keywords has-patch added

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

8 years ago

#3 @SergeyBiryukov
8 years ago

  • Component changed from Administration to Export

#4 @joedolson
8 years ago

  • Milestone changed from Awaiting Review to Future Release

As noted in #37648:

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.

#5 @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!

(And yes, I did cut and paste this comment from the other ticket...)

#6 @mercime
8 years ago

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

Hi @joedolson. Please note that this patch also includes adding a <label> tag to a <select> form control which is required.

As to 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.

#7 @afercia
8 years ago

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

Going to close this as per comment on the related ticket, see: ticket:37648#comment:8

Note: See TracTickets for help on using tickets.