accessible-emoji
<span>
and provide screenreader access.<span>
element with appropriate aria
attributes, making web content more inclusive for visually impaired users.
role="img"
attribute alongside aria-label
or aria-labelledby
for emojis, which provides semantic meaning and a textual alternative, crucial for understanding the content’s context in screen reader scenarios.
alt-text
<img>
, <object>
, <area>
, <input type="image">
, and custom components simulating these behaviors, have alternative text, enhancing web accessibility for users relying on screen readers to understand the content. Non-text content must have text alternatives that present the equivalent information to ensure that it can be accessed by people with various disabilities.
anchor-ambiguous-text
<a>
text to not exactly match “click here”, “here”, “link”, or “a link”.<a>
elements rather than generic phrases like “click here,” the rule helps ensure that users, especially those using screen readers, have a clearer understanding of the link’s destination. This makes navigation and comprehension of web content more accessible.
anchor-has-content
<a>
) elements in JSX have accessible content, which is critical for users who rely on screen readers to navigate content on the web. Without accessible content, these users may encounter anchor elements that provide no context or indication of their function or destination.title
, aria-label
) that can describe the purpose or destination of the link to assistive technologies. This caters to a variety of use cases, including those where visual design constraints might discourage visible text.<a>
tag, the rule acknowledges and adapts to the common practice in modern web development frameworks and libraries (like React) of creating reusable component libraries. This ensures that accessibility considerations are extended to these custom components as well.anchor-is-valid
<a>
tags) only for navigation purposes and buttons for clickable actions. This distinction is crucial for accessibility as it helps screen readers and other assistive technologies interpret the purpose of elements correctly.
href
attribute or improperly using JavaScript URLs. These practices can undermine the navigability and security of a web application, leading to a poor user experience, especially for those relying on assistive technologies.
noHref
, preferButton
, invalidHref
) allow teams to tailor the rule to their specific project needs, making it a versatile tool for maintaining both code quality and accessibility standards. This flexibility ensures that the rule can adapt to various coding styles and project requirements without enforcing overly strict guidelines that might not fit every scenario.
aria-activedescendant-has-tabindex
aria-activedescendant
attribute are also interactive or focusable by requiring a tabIndex
. This is crucial because aria-activedescendant
is used to manage focus among child elements when the container receives focus. Without tabIndex
, keyboard users might not be able to interact with these elements as intended.
aria-activedescendant
accessible to keyboard navigation. This rule enforces that such elements must be tabbable (by setting a valid tabIndex
), which is essential for users who rely on keyboard navigation to access content on the web.
aria-activedescendant
but lack a tabIndex
. This preemptive checking saves developers time and ensures a smoother, more accessible user experience without needing extensive manual review or user feedback to identify these issues.
aria-props
aria-*
props are valid.aria-*
props are valid aids screen readers and assistive technologies in interpreting the web content correctly.aria-proptypes
aria-checked
instead of Boolean), this rule aids developers in adhering to ARIA specifications and best practices, reducing the likelihood of accessibility issues caused by incorrect attribute values.aria-role
ignoreNonDOM
) to skip validation for non-DOM elements. This flexibility allows developers to focus on validating roles in contexts where it matters most, such as in actual rendered HTML, while avoiding unnecessary checks in situations where an element might not directly correlate to a DOM element, thus optimizing development efficiency without compromising on accessibility.
allowedInvalidRoles
, where developers can specify exceptions. This makes the rule adaptable to unique project requirements or when integrating with libraries or frameworks that might use roles in non-standard ways but are still accessible. This adaptability ensures that teams can enforce accessibility standards while also accommodating valid exceptions specific to their project’s context.
role
and its value isn’t undefined
or null
. This precision prevents false positives and ensures that developers are alerted only in cases where an invalid ARIA role could genuinely affect accessibility. It focuses on actual issues rather than potential syntactic anomalies, thereby streamlining the debugging process and ensuring that efforts are concentrated on making meaningful improvements to accessibility.
aria-unsupported-elements
role="presentation"
to a <meta>
tag, which does not support ARIA roles, can mislead screen readers and other assistive devices.
autocomplete-valid
autocomplete
attribute in JSX components, which directly contributes to improving the user experience by allowing browsers to predict the user’s input, thereby speeding up the form-filling process.
autocomplete
values, the rule aids in enhancing form accessibility, making it easier for people with disabilities to fill out forms. Autocomplete hints assist in reducing the amount of typing required, which is particularly beneficial for users with motor disabilities.
autocomplete
attributes, the rule ensures that developers follow a consistent pattern, reducing bugs related to incorrect form behavior and improving code maintainability.
click-events-have-key-events
control-has-associated-label
heading-has-content
h1
, h2
, etc) elements contain accessible content.h1
, h2
, etc.) in JSX elements contain accessible content, which is critical for users who rely on screen readers to navigate web content. By enforcing this rule, developers are prompted to include meaningful text within headings, improving the site’s accessibility.
context.report
method when a violation is detected, it provides direct feedback to developers about where and why a violation occurs. This immediate feedback loop helps in educating developers about accessibility best practices and encourages the correction of issues at the source. The rule not only identifies the problem but guides towards a solution, thereby fostering an environment of continuous improvement and learning regarding accessibility.
html-has-lang
<html>
element has lang
prop.lang
attribute in <html>
elements, which is crucial for screen readers to provide accurate language support, enhancing the experience for users who rely on assistive technologies.iframe-has-title
img-redundant-alt
<img>
alt prop does not contain the word “image”, “picture”, or “photo”.interactive-supports-focus
onClick
must be focusable.onClick
, must also be focusable. This is crucial because it allows users who rely on keyboard navigation to interact with all interactive elements.divs
used as buttons) to be explicitly made focusable through attributes like tabIndex
. This directly benefits users who use assistive technologies.div
with an onClick
handler should have an appropriate role (e.g., role="button"
) if it is acting as a button. This semantic clarity helps assistive technologies interpret and interact with web content effectively.label-has-associated-control
label
tag has a text label and an associated control.input
, textarea
, etc.), either by nesting the control within the label or using the htmlFor
attribute. This practice improves form accessibility for users relying on assistive technologies to navigate and interact with your website or application.htmlFor
, nesting
, both
, or either
), giving developers control over how strict their accessibility checks are. This can be adjusted to match project-specific accessibility standards or to progressively improve accessibility in large codebases.label-has-for
<label>
elements have the htmlFor
prop.<label>
elements are properly associated with their corresponding input elements through the htmlFor
prop. This association is crucial for screen reader users to understand the form structure and interact with it effectively.htmlFor
prop is missing or improperly used, this rule helps to streamline the development process, reduce human error, and ensure that accessibility considerations are systematically integrated into the codebase from the very beginning.lang
lang
attribute in JSX elements. This is crucial because the language attribute helps assistive technologies like screen readers pronounce text correctly, improving the experience for users with disabilities.
lang
attribute, this rule indirectly supports internationalization efforts. A correctly specified language tag enables browsers and search engines to properly classify and process the content, thereby improving global user reach and engagement.
lang
attribute to offer language-specific search results. Pages with accurately defined lang
attributes are better indexed, which can lead to improved search engine visibility and rankings for content in the specified language.
lang
attribute, the rule encourages developers to pay attention to important but often overlooked aspects of HTML element attributes. This focus on detail leads to overall better code quality and adherence to best practices in web development.
media-has-caption
<audio>
and <video>
elements must have a <track>
for captions.<audio>
and <video>
elements include captions for the deaf or hard of hearing, enhancing web inclusivity and complying with various accessibility standards and laws.<audio>
or <video>
elements are missing <track>
tags designated for captions, thus helping developers catch and resolve potential accessibility issues early in the development process.<track>
elements, this rule indirectly encourages content creators to provide translations, fostering an environment where content is accessible to non-native speakers or to audiences with different language preferences.mouse-events-have-key-events
onMouseOver
/onMouseOut
are accompanied by onFocus
/onBlur
for keyboard-only users.onMouseOver
and onMouseOut
have corresponding keyboard events onFocus
and onBlur
. This makes sure elements interactive with a mouse are also accessible through the keyboard.no-access-key
accessKey
prop is not used on any element to avoid complications with keyboard commands used by a screenreader.accessKey
attribute which can interfere with screen reader shortcuts, ensuring that users relying on assistive technologies have a consistent and accessible experience when navigating web applications.
no-aria-hidden-on-focusable
no-autofocus
autoFocus
prop on elements. The autoFocus prop can negatively impact users with disabilities, as it might lead to an unexpected change in the focus, making navigation confusing for screen reader users and those with cognitive disabilities.
autoFocus
prop directly and instead consider alternative, more accessible solutions, such as conditionally focusing an element based on user actions or component states, it encourages a more thoughtful approach to setting focus that respects the user’s intention and control.
useRef
and useEffect
in React for focusing elements programmatically demonstrates an accessible alternative to autoFocus. It provides developers with a practical, accessible method to set focus when necessary, such as focusing on an input field when a form is shown, without automatically moving focus as soon as the component mounts. This approach offers a balance between usability and accessibility, ensuring that focus management is done in a user-friendly and A11Y-compliant manner.
no-distracting-elements
<marquee>
or <blink>
, it makes web content more accessible to users with attention disorders or visual impairments, adhering to Web Content Accessibility Guidelines (WCAG).
no-interactive-element-to-noninteractive-role
no-noninteractive-element-interactions
<div>
s, do not have mouse or keyboard event listeners, pushing for the use of semantically correct interactive elements like <button>
.<div>
or <span>
which are not traditionally clickable do not perform interactive roles without proper roles and attributes.no-noninteractive-element-to-interactive-role
<li>
tags, from being assigned interactive roles, such as button
, which can confuse assistive technologies and users about the element’s functionality.<button>
, rather than repurposing non-interactive elements through roles and event listeners, leading to cleaner and more maintainable code.no-noninteractive-tabindex
tabIndex
should only be declared on interactive elements.tabIndex
are indeed interactive, as non-interactive elements with a focusable state can confuse users navigating a site with assistive technologies.tabIndex
, helping developers catch and correct potential mistakes that could lead to a poor user experience for people relying on keyboard navigation.<button>
over <div>
with a tabIndex
for clickable elements), which is a key principle of web accessibility.no-onchange
onBlur
over onChange
on select menus for accessibility.onBlur
instead of onChange
for select elements, which can prevent unexpected behavior for keyboard and screen reader users. This adaptation aims to enhance the interaction experience for users relying on assistive technologies.onChange
can cause issues in certain assistive technologies by triggering changes as soon as the selection is changed, which might not be the user’s intent. onBlur
, on the other hand, waits until the element loses focus, aligning actions more closely with user intentions.onChange
without a corresponding onBlur
handler on select elements, thereby aiding in the swift correction of accessibility flaws in existing and new codebases.no-redundant-roles
<nav>
element to “navigation” is redundant since “navigation” is already its implicit role. By removing such redundancies, the code becomes easier to read and maintain.
no-static-element-interactions
<div>
) that have click handlers use the role attribute.<div>
with click handlers to have a role
attribute, it makes these elements perceivable and usable for users navigating via screen readers or other assistive devices.
<div>
used as buttons helps communicate the intended behavior semantically, improving code clarity and maintainability.
prefer-tag-over-role
role
property.<button>
instead of <div role="button">
) helps users with assistive technologies understand and navigate the content more effectively.
role-has-required-aria-props
aria-checked
attribute in elements with role="checkbox"
.aria-checked="false"
to make the role of the element clear and operable.role-supports-aria-props
aria-*
properties supported by that role
.aria-*
properties for their role, it prevents developers from mistakenly using ARIA attributes that are not applicable to the element’s role, which could otherwise lead to confusion for users of assistive technology.role
attribute) and implicit roles (determined by the element type and its context), which is crucial because it covers a wider range of scenarios, ensuring that even elements without an explicitly set role follow the ARIA properties guidelines.aria-*
properties for a given role by comparing the used properties against a set of supported properties for the detected role. This targeted approach helps in catching and mitigating common accessibility issues at the development stage, contributing to a more accessible web.scope
scope
prop is only used on <th>
elements.scope
attribute is correctly applied to table headers (<th>
elements), which helps screen readers and other assistive technologies understand the structure of the data, improving the experience for users with disabilities.scope
attribute on elements other than <th>
, such as <td>
, which could lead to misleading information being presented to assistive technologies, thus avoiding confusion and making the content more accessible and semantically correct.scope
attribute, making it easier for developers to follow best practices in web development without having to remember specific accessibility guidelines, thus ensuring a higher quality of code.scope
attribute, this rule saves developer time and reduces the likelihood of accessibility defects being introduced during development, leading to a more efficient development process and reducing the need for extensive accessibility audits later on.tabindex-no-positive
tabIndex
value is not greater than zero.tabIndex
values do not exceed zero is essential for creating a web navigation structure that is logical and predictable. Positive values can disrupt the natural order of keyboard navigation, leading to a confusing experience for users who rely on assistive technologies.tabIndex
of zero or negative, developers are encouraged to rely on the natural DOM order for keyboard navigation, which is generally more intuitive and accessible.tabIndex
means it specifically targets easily identifiable and correctable instances where the tabIndex
might be improperly set. This clarity can expedite the process of identifying and addressing accessibility issues related to focus management.tabIndex
for review, this ESLint rule can serve as an educational tool for developers, highlighting an often-overlooked aspect of accessible web design. As developers adjust their coding practices to comply with this rule, they inherently learn more about accessible web development principles.