Code Inspections in HTML
This topic lists all JetBrains Rider code inspections available in HTML.
Accessibility
Missing associated label
Warning
Missing required ‘alt’ attribute
Reports a missing alt attribute in a img or applet tag or in a area element of an image map. Suggests adding a required attribute with a text alternative for the contents of the tag. Based on WCAG 2.0: H24, H35, H36, H37.
Warning
Missing required ‘lang’ attribute
Reports a missing lang (or xml:lang ) attribute in a html tag. Suggests adding a required attribute to state the default language of the document. Based on WCAG 2.0: H57.
Warning
Missing required ‘summary’ attribute
Reports a missing summary attribute in a table tag. Suggests adding a summary attribute. Based on WCAG 2.0: H73.
Missing required ‘title’ attribute
Missing required ‘title’ element
Reports a missing title element inside a head section. Suggests adding a title element. The title should describe the document. Based on WCAG 2.0: H25.
Warning
Other inspections
Reports an empty tag (such as script ) that does not work in some browsers.
Warning
Incorrect boolean attribute
Reports an HTML non-boolean attribute without a value. Suggests configuring attributes that should not be reported.
Warning
Malformed content of ‘script’ tag
Reports invalid XML contents of a script tag.
Error
Mismatched image size
Reports a width and height attribute value of a img tag that is different from the actual width and height of the referenced image.
Warning
Missing closing tag
Reports an HTML element without a closing tag. Some coding styles require that HTML elements have closing tags even where this is optional.
label-has-associated-control error with label/input #632
Comments
fritogotlayed commented Aug 15, 2019 •
Output from the run config appears that this case should be covered and function properly via the documentation and conversation in another issue I initially read as identical. From what I’m seeing in the output the depth here is 25 so I’m confused as why this is not working as I believe it should.
ESLint run output snippet:
Relevant snippet from eslint run rules:
The text was updated successfully, but these errors were encountered:
ljharb commented Aug 15, 2019
The «both» assert means that the input has to also be inside the label. If you change it to «either» or «htmlFor», it will permit your example.
fritogotlayed commented Aug 15, 2019
@ljharb You sir are a rockstar! I apologize for creating a bit of distraction on the other issue. Switching from «both» to «either» knocked it right out. For anyone who may stumble here and is also using the yml format:
ljharb commented Aug 15, 2019
I would, however, suggest nesting the input inside the label, since doing both covers more assistive devices and allows the maximal amount of people to use the input properly.
hades200082 commented May 26, 2020
One of the most common UI frameworks out there, Bootstrap, uses the for=»» method and does not use nesting in any of their documented examples.
The overall accessibility of any project built with Bootstrap depends in large part on the author’s markup, additional styling, and scripting they’ve included. However, provided that these have been implemented correctly, it should be perfectly possible to create websites and applications with Bootstrap that fulfill WCAG 2.0 (A/AA/AAA), Section 508 and similar accessibility standards and requirements.
This seems to indicate that both are indeed NOT required when using the for=»» form and that you can still achieve a highly accessible website without nesting.
ljharb commented May 26, 2020
(also, please don’t cross-post the same comment both here and here, it’s noise)
hades200082 commented May 26, 2020
If Bootstrap can support WCAG 2.0 AAA as indicated by their documentation how are they not concerned?
ljharb commented May 26, 2020
hades200082 commented May 26, 2020
It sounds more like you have a personal axe to grind on this subject. By continuing to support outdated and non-compliant devices you’re perpetuating their continued production and sale/usage.
The biggest obstacle in many businesses (particularly SMEs) to building accessible websites is the cost of development. Indeed, issues such as this one which take more skill and development effort to overcome add to that cost.
Surely it would be better to guide the industry that is making such devices towards adopting standards that make developing accessible websites easier so that more companies & developers can do so within their budgets?
By your current argument all websites should still be using only HTML/CSS/JS that is supported by IE6 because there are a large number of people in the world that are still stuck with that browser.
ljharb commented May 26, 2020
If my personal axe is “not excluding human beings”, then you’re right 🙂
Supporting old devices/platforms is critical for those that can’t update. Not supporting them is hostile. Nobody’s using an old platform because they want to. As for non-compliance, again, hurting people isn’t a just way to force a corporation to change.
Adding both nesting and for-ID linking isn’t a large cost. Airbnb has 30,000+ react components (as of last July) and all form controls use this approach.
hades200082 commented May 27, 2020
The difference here is that a hearing-impaired user on modern Chrome will still be screwed if you don’t follow this recommendation
I didn’t realise that hearing had anything to do with ability to read or use a website form?
why are you advocating to discriminate against them?
I’m not advocating or discriminating against anyone. I’m stating that standards exist to allow companies and developers to provide for these types of people in a way that is economically and technically viable for smaller businesses that can’t spend millions on developers.
By enforcing your very narrow view all that will happen is that those companies and their developers will, at best, simply ignore the warnings your package throws up and at worst, remove the package or disable it.
Rather than fighting a crusade that will lead to the opposite of your intended goal, why not work with the established standards and use your knowledge and influence to work with the people defining the standards to improve them. Likewise, working with the developers of assistive technology to help them to better adhere to those standards.
The web became a better place, both for users and for developers when the W3C was formed and browser vendors started working together to produce comparable user experiences across different devices and browsers. Why should assistive tech be any different?
hades200082 commented May 27, 2020
It’s also worth noting that I have checked the websites of several accessible browsers and none of them follow this recommendation themselves.
ljharb commented May 28, 2020
Sorry, you’re right; i meant vision-impaired. My mistake.
qkreltms commented Aug 7, 2020 •
Seems not working when you use styled-component any ideas?
control-has-associated-label error with label/input? #566
Comments
leepowelldev commented Mar 15, 2019
We are getting linting errors with this rule for simple JSX such as:
Both result in Error: A control must be associated with a text label jsx-a11y/control-has-associated-label
Our rule is setup as:
Do we need to pass the second argument object to the rule? or should this be supported out of the box?
The text was updated successfully, but these errors were encountered:
leepowelldev commented Mar 15, 2019
Our config looks like:
Am I missing something here?
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
leepowelldev commented Mar 18, 2019 •
Currently we’re having to disable this rule based on our code usage shown above.
ljharb commented Mar 18, 2019
soundasleep commented May 20, 2019
We are having this warning thrown up as well:
==> 37:5 error A form label must be associated with a control jsx-a11y/label-has-associated-control
For now, we’re turning off the jsx-a11y/label-has-associated-control rule.
jcollum-nike commented May 20, 2019 •
Tried a few variations of the for property with no success.
ljharb commented May 21, 2019
It’s called htmlFor, not for
jcollum-nike commented May 21, 2019 •
I did fix it though:
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
OZZlE commented Oct 13, 2020
ljharb commented Oct 13, 2020
@OZZlE depending on your config, you may need to also for-ID link the two, as well as nest them.
OZZlE commented Oct 14, 2020 •
@OZZlE depending on your config, you may need to also for-ID link the two, as well as nest them.
If I still have to use htmlFor and id then it totally defeats the purpose. You nest the input inside to add a connection that Screenreaders understands and all other browsers as well. You can click the label and that will focus the input.
ljharb commented Oct 14, 2020
Yes, the airbnb config requires both nesting and for-ID linking of labels and inputs. Both are required for full a11y coverage. You also want nesting because it increases the interaction area for the input, even if things are linked.
OZZlE commented Oct 14, 2020 •
ljharb commented Oct 14, 2020
You’d copy the rule config from the airbnb config into your project config, and then edit it so it had the settings you like.
OZZlE commented Oct 20, 2020 •
This is the closest I got to what I wanted (either label nests form element or uses htmlFor):
Unfortunately it doesn’t complain if you don’t use any Label at all for a form element. but it seems the be the same with the default eslint.
antony2025 commented Nov 25, 2020 •
This is what I had to add to get either htmlFor or nesting:
ljharb commented Nov 26, 2020
This seems answered.
leepowelldev commented Nov 26, 2020
How is this answered? Most of the comments are around ‘label-has-associated-control’ rather than finding the reverse relationship from a control to its label with ‘control-has-associated-label’.
ljharb commented Nov 28, 2020
this rule might need the same “assert” options as the inverse rule
Missing associated label что это
Enforce that a label tag has a text label and an associated control.
There are two supported ways to associate a label with a control:
This rule checks that any label tag (or an indicated custom component that will output a label tag) either (1) wraps an input element (or an indicated custom component that will output an input tag) or (2) has an htmlFor attribute and that the label tag has text content.
How do I resolve this error?
Case: I just want a text label associated with an input.
The simplest way to achieve an association between a label and an input is to wrap the input in the label.
All modern browsers and assistive technology will associate the label with the control.
Case: The label is a sibling of the control.
In this case, use htmlFor and an ID to associate the controls.
Case: My label and input components are custom components.
You can configure the rule to be aware of your custom components.
And the configuration:
Case: I have two labels for the same input
If the second label is in a different part of the HTML, then the second one can only contain htmlFor but not nesting. You will probably need eslint override comment on the second label.
How to manage IDs of input
A common way to think of id with libraries like React is, id s should be avoided since it must be unique on the page, and components need to be reusable. Hence it is tempted to generate id during render-time if id is required. However:
IDs shouldn’t be generated in the browser, so that server and client rendering are deterministic. Render-time uuids aren’t just a hack, they’re actually broken and should never be used.
To restate, every ID needs to be deterministic, on the server and the client, and guaranteed to be unique on the page. EG: For each input, a required ID prop can be passed down from as far up the tree as possible to guarantee uniqueness.
This rule takes one optional object argument of type object:
Empty or Missing Form Label
Did an “Empty Form Label” or “Missing Form Label” error appear in an Accessibility Checker audit of one of your WordPress posts or pages? Read on below for an explanation of these errors, how they impact your website’s accessibility, and how to fix them.
Table of Contents
About the Empty Form Label and Missing Form Label Errors
What is a form label?
A form label is an HTML element used in forms to describe what the the various fields and controls in the form are for.
Regardless of the type of field you’re using, whether it is radio buttons, checkboxes, dropdown selects, or text fields, there must be a element properly associated with the form control, either implicitly or explicitly. Labels can be visible above each field as shown in the following screenshot of the top of our Free Risk Assessment Form:
Or, labels can also be located below, next to, or even after each field, as shown in this screenshot of part of an email opt-in form:
Regardless of placement, properly formatted labels are necessary because they ensure that users of assistive technology like screen readers will know what to enter into each field. They also can provide a larger clickable area which helps people with lower dexterity, including the elderly, to move more easily through a form with both a mouse or on a touchscreen like a mobile phone.
How are labels associated with fields?
For most WordPress users, labels are added to fields as you build your form in whatever WordPress forms plugin you’re using. Usually, all you have to do is fill in a field on the form edit screen, like in this screenshot which shows the editing experience for a text field within the Gravity Forms plugin:
Once you have filled in the “Field Label” section for each field, your form plugin should display the label automatically.
The above example shows the HTML code for the subscribe form image that was embedded earlier on the page containing a name field and subscribe checkbox. Note that the labels can either preceded or follow their associated input.
There are several other ways that you can label form controls in an accessible manner. These methods are outlined in W3C’s Web Accessibility Tutorials “Labeling Controls” if you would like to learn more.
What qualifies as an empty form label?
An Empty Form Label error is triggered when a tag is present in your form and associated with an input (form field), but does not contain any text. Here is an example of an empty label in code:
Form labels are also considered empty if they wrap around the tag and contain no other text like this:
What qualifies as a missing form label?
A Missing Form Label error is triggered when an (form field) is present in your form and but is not associated with a element. This could look like this, where the label is present but is missing a for=»» attribute to connect it to the applicable field:
Or there could be no label present at all and only an tag.
How does Accessibility Checker test for empty and missing form labels?
Impact on Accessibility
Why are form labels important?
Form labels are necessary so that users of assistive technology will know what the field is for and will be able to successfully fill out the form.
Without form labels, a screen reader will only read out the type of the field. For a text field that has an empty label, a screen reader might say only “Edit,” “Edit has auto complete,” or “Edit text, blank.” PowerMapper has a useful page on their website where they have documented what the major screen readers say when presented with an empty form label; if you go to that page you can hear a recording of what different screen readers in different browsers say when encountering empty labels.
It goes without saying that if a person does not know what is supposed to be filled into each field, they cannot possibly complete the form.
Approximately 12 million people 40 years and over in the United States have vision impairment, including 1 million who are blind, 3 million who have vision impairment after correction, and 8 million who have vision impairment due to uncorrected refractive error.
If visitors to your website cannot fill out forms on your website, they will not be able to inquire about services, make a purchase, contact you, sign up for your newsletter, or take any other actions that require a form fill. Not only does this limit their ability to fully engage with your website but it also reduces the possible audience for your products and/or services and will lower your conversion rate. Form labels are just as good for your business as they are for your website’s visitors.
Placeholder text is not a substitute for empty or missing form labels
Designers commonly design forms for websites that do not show the form labels and instead use placeholder text within the field to try and denote what the field is for. This is especially common for short forms with few fields like email newsletter signup forms, but we’ve seen this technique used even in very long forms.
Example of a common email newsletter subscription section on a website without a visible form label on the email address field and using placeholder text instead.
Though we understand the design value of a cleaner more minimalistic appearance it is incorrect to use placeholder text as a replacement for labels. Screen readers and other assistive technologies do not treat placeholder text as labels, which means that they do not always read or announce the presence of placeholder text. Placeholder text is not broadly supported across all assistive technologies and many older browsers do not display placeholder text at all, which means that both sighted and blind users could be left without knowing what the field is for if there is not also a label for that field.
In addition to not being universally supported by assistive technologies, placeholder text also is bad for accessibility because:
These four accessibility problems impact all visitors to your website, not just users with disabilities.
The Nielsen Norman Group, experts in research-based user experience, has an excellent article, “Placeholders in Form Fields Are Harmful,” which provides additional information about why you should never use placeholder text because the resulting loss in useability will also decrease conversion rates. You can also see examples of problems caused by placeholders in Smashing Magazine’s “Don’t Use The Placeholder Attribute” article.
What if I really want to hide my form labels for aesthetic reasons?
Unfortunately, there is no way to hide form labels and have an accessible form. There are tutorials on the web for making hidden form labels available to screen readers, which does make them accessible to blind and visually impaired users of screen readers, however this does not resolve the issues described above about how missing form labels can negatively impact sighted users.
All people need to be able to easily understand how to fill in the forms on your website and visible labels are necessary for that. If you’re hoping to have a more modern or minimalistic design, there are still great ways to still accomplish that aesthetic without removing form labels.
Relevant WCAG 2.1 Success Criteria
1.1.1 Non-text Content – Level A
If non-text content is a control or accepts user input, then it has a name that describes its purpose.
1.3.1 Info and Relationships – Level A
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
2.4.6 Headings and Labels – Level AA
Headings and labels describe topic or purpose.
3.3.2 Labels or Instructions – Level A
Labels or instructions are provided when content requires user input.
4.1.2 Name, Role, Value – Level A
For all user interface components (including but not limited to: form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
How to Fix an Empty or Missing Form Label Error
What to do (in short)
To fix empty or missing form label errors, you’ll need to determine how the field and form were created and then either add text to your existing field label or add field labels if they are missing completely.
How to find and fix Empty Form Label and Missing Form Label errors in WordPress
For any pages or posts that have either an Empty Form Label error or a Missing Form Label error in the WordPress editor, you can open the details tab in the Accessibility Checker meta box, then expand the applicable error to see a list of code that caused the error to appear.
The above screenshot shows an example of a form label that has been flagged as empty. This particular example is a label within a WP Forms form. Ideally you only have one form plugin on your website and one form per post or page, but if you have multiple and are not sure what label this is referencing you can look at the code for clues.
In this code snippet, we can clearly see “wpforms” in the label’s class which tells us this label is part of a form built in WP Forms. The for attribute provides is with the unquie field ID which is sometimes helpful in finding the specific field as some plugins display the field ID in their backend form builder. WP Forms does not, unfortunately, but you likely don’t actually need to know which field this is by ID as it should be visually obvious to you when looking at your form if there are labels missing.
If you see a missing or empty form label error in Accessibility Checker, the best course of action is to open your form builder and add labels to all fields in every form or ensure that any options within the form settings to hide labels are unselected.
What if your forms have missing or empty labels you cannot find or fix?
Depending upon how you have added forms to your WordPress website, it possible you may encounter empty or missing form labels that you cannot correct. This is less likely to happen with a form building plugin, but more likely to happen if you have embedded code that includes a form from a third-party source or if there is a minimally (or not at all) configurable form included in a different type of WordPress plugin, such as a user registration or membership plugin, an email newsletter plugin, or e-commerce plugin.
In that case, you may need to choose a different plugin to use on your website or will need to contact the provider of the code you have used for assistance. If you encounter accessibility errors that are caused by a third-party plugin you cannot control, please reference “What to do if a Plugin You’re Using has Accessibility Errors” for ideas on how to proceed.
