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: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Export | Keywords: | has-patch |
Focuses: | accessibility | Cc: |
Description
Some input
fields and select
form controls are not bound to respective label
s on this screen. Attached patch fixes the issue for accessibility.
Attachments (1)
Change History (8)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#5
@
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
@
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
@
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
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.