new a11y rule: Labels must be explicitly associated with their controls

HamletDRC commented 8 years ago

"A label is implicitly associated with its form control either through markup or positioning on the page."

<LABEL for="firstname">First name: 
    <INPUT type="text" id="firstname" tabindex="1">
</LABEL>

references

    <label for="favoritecolor">Your Favorite Color</label>
    <input name="FavoriteColor" type="text" id="favoritecolor" />

"For checkboxes and radio buttons, use the

and elements to get everything labeled properly."

<fieldset>
  <legend>Your Favorite Color</legend>
  <input type=”radio” name=”favoritecolor” value=”blue” id=”  blue”>
  <label for=”blue”>Blue</label>
  <input type=”radio” name=”favoritecolor” value=”green” id=”green”>
  <label for=”green”>Green</label>
  <input type=”radio” name=”favoritecolor” value=”purple” id=”purple”>
  <label for=”purple”>Purple</label>
</fieldset>

From https://github.com/globant-ui/arialinter/blob/master/lib/rules/inputAssistance.js:

Each fieldset element should contain a legend element (http://oaa-accessibility.org/wcag20/rule/73/)
The label element should not encapsulate select and textarea elements (http://oaa-accessibility.org/wcag20/rule/74/)
Each input element with type=text | password | checkbox | radio | file and each select and textarea element should either be referenced by the for attribute of a label element via its id attribute, or have a title attribute. (http://oaa-accessibility.org/wcag20/rule/75/)
Input elements where type=[button|submit|reset] must have a value or title attribute (http://oaa-accessibility.org/wcag20/rule/77/)
Each button element must contain content (http://oaa-accessibility.org/wcag20/rule/78/)
Effective labels should be unique (http://oaa-accessibility.org/wcag20/rule/79/)
Labels must have text content (http://oaa-accessibility.org/wcag20/rule/80/)
Legends must have text content (http://oaa-accessibility.org/wcag20/rule/81/)
Title attributes used for labeling form controls must have content (http://oaa-accessibility.org/wcag20/rule/82/)
Form controls must have unique ids. (http://oaa-accessibility.org/wcag20/rule/83/)

From HTML Code Sniffer (https://squizlabs.github.io/HTML_CodeSniffer/Standards/WCAG2/):

Multiple labels exist with the same "for" attribute. If these labels refer to different form controls, the controls should have unique "id" attributes (http://www.w3.org/TR/WCAG20-TECHS/H93)
This label's "for" attribute contains an ID that does not exist in the document. (http://www.w3.org/TR/WCAG20-TECHS/H44)
This label's "for" attribute contains an ID that points to an element that is not a form control. (http://www.w3.org/TR/WCAG20-TECHS/H44)
Form control does not have an ID, therefore it cannot have an explicit label. (http://www.w3.org/TR/WCAG20-TECHS/H44)
Label element should not be used for this type of form control. "Form controls which do not require a label, yet one has been provided. Button and hidden elements fall into this category - buttons have a label already (the text on the button), while the latter makes no sense." (http://www.w3.org/TR/WCAG20-TECHS/H44)
The label element for this control should be placed after this element.. "Form control where the label should be placed after the element, but not. Radio and checkbox inputs fall into this category" (http://www.w3.org/TR/WCAG20-TECHS/H44)
The label element for this control should be placed before this element. Form control where the label should be placed before the element, but not. Textbox based inputs fall into this category (including text, textarea, password, file upload, ...).. (http://www.w3.org/TR/WCAG20-TECHS/H44)
"Semantic markup should be used to mark emphasised or special text so that it can be programmatically determined.", "Semantic markup should be used to mark emphasised or special text so that it can be programmatically determined.", "Paragraph of text that appears to have bold or italic content (whether through b/i or strong/em) as its only child.".
- https://github.com/squizlabs/HTML_CodeSniffer/blob/master/Standards/WCAG2AAA/Sniffs/Principle1/Guideline1_3/1_3_1.js
- http://www.w3.org/TR/WCAG20-TECHS/H49

Use title when label not available: https://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H65"The objective of this technique is to use the title attribute to label form controls when the visual design cannot accommodate the label"

<input id="areaCode" name="areaCode" title="Area Code" type="text" size="3" value="" >

or

<input type="text" title="Type search term here"/>

Form does not contain a submit button (input type="submit", input type="image", or button type="submit").

From HTML Code Sniffer SC 4.1.2: Name, Role, Value (Level A)

http://www.w3.org/TR/WCAG20-TECHS/H91
Form control which does not have a valid accessibility API "name". The message states which items count as a valid "name".
Form control which does not have a valid accessibility API "value". The message states how to add a valid value.

input type="checkbox" elements must have a group and that that group designation must be consistent - axe-core checkboxgroup. Ensure related input type="radio" elements have a group and that the group designation is consistent - axe-core radiogroup

astorije commented 6 years ago

For the record, the ESLint equivalent of this is label-has-associated-control, formerly known as label-has-for.

JoshuaKGoldberg commented 5 years ago

💀 It's time! 💀

TSLint is being deprecated; therefore, it and tslint-microsoft-contrib are no longer accepting pull requests for major new changes or features. See https://github.com/palantir/tslint/issues/4534. 😱

If you'd like to see this change implemented, you have two choices:

Recommended: Check if this is available in ESLint + typescript-eslint ✅
Not Recommended: Fork TSLint or tslint-microsoft-contrib locally 🤷‍♂️

👋 It was a pleasure open sourcing with you!

If you believe this message was posted here in error, please comment so we can re-open the issue!

microsoft / tslint-microsoft-contrib

new a11y rule: Labels must be explicitly associated with their controls #271

💀 It's time! 💀