Common - CodeAnt AI

Non-interactive DOM elements should not have the `tabIndex` property

The misuse of the tabIndex attribute can lead to several issues:

Navigation Confusion: It can confuse users who rely on keyboard navigation, as they might expect to tab through interactive elements like links and buttons, not static content.
Accessibility Issues: It can create accessibility problems, as assistive technologies provide their own page navigation mechanisms based on the HTML of the page. Adding unnecessary tabindexes can disrupt this.
Increased Tab Ring Size: It unnecessarily increases the size of the page’s tab ring, making navigation more cumbersome.

<div tabIndex="0" />

Label elements should have a text label and an associated control

When a label element lacks a text label or an associated control, it can lead to several issues:

Poor Accessibility: Screen readers rely on correctly associated labels to describe the function of the form control. If the label is not properly associated with a control, it can make the form difficult or impossible for visually impaired users to understand or interact with.
Confusing User Interface: Labels provide users with clear instructions about what information is required in a form control. Without a properly associated label, users might not understand what input is expected, leading to confusion and potential misuse of the form.
Code Maintainability: Properly structured and labeled code is easier to read, understand, and maintain. When labels are not correctly associated, it can make the code more difficult to navigate and debug, especially for new developers or those unfamiliar with the codebase.

Control elements are:

`<input>
<meter>
<output>
<progress>
<select>
<textarea>`

<input type="text" />
<label>Favorite food</label>

Anchors should contain accessible content

Anchors, represented by the a tag in HTML, usually contain a hyperlink that users can click to navigate to different sections of a website or different websites altogether.

However, when anchors do not have content or when the content is hidden from screen readers using the aria-hidden property, it creates a significant accessibility issue. If an anchor’s content is hidden or non-existent, visually impaired users may not be able to understand the purpose of the anchor or navigate the website effectively.

This rule checks that anchors do not use the aria-hidden property and have content provided either between the tags or as aria-label or title property.

<a aria-hidden>link to my site</a>

Focusable elements should not have aria-hidden attribute

ARIA (Accessible Rich Internet Applications) is a set of attributes that define ways to make web content and web applications more accessible to people with disabilities. The aria-hidden attribute is used to indicate that an element and all of its descendants are not visible or perceivable to any user as implemented by assistive technologies.

However, when aria-hidden is used on a focusable element, it can create a confusing and inaccessible experience for screen reader users. This is because the element will still be included in the tab order, so a screen reader user can navigate to it, but it will not be announced by the screen reader due to the aria-hidden attribute.

This rule ensures that focusable elements are not hidden from screen readers using the aria-hidden attribute.

<button aria-hidden="true">Click me</button>

Elements with an interactive role should support focus

Lack of focusability can hinder navigation and interaction with the website, resulting in an exclusionary user experience and possible violation of accessibility guidelines.

<!-- Element with mouse/keyboard handler has no tabindex -->
<span onclick="submitForm();" role="button">Submit</span>

<!-- Anchor element without href is not focusable -->
<a onclick="showNextPage();" role="button">Next page</a>

Statements should be on separate lines

Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.

Unresolved directive in <stdin> - include::{noncompliant}[]

Write one statement per line to improve readability.

Unresolved directive in <stdin> - include::{compliant}[]

if (someCondition) doSomething(); // Noncompliant

Ternary operators should not be nested

Nested ternaries are hard to read and can make the order of operations complex to understand.

Unresolved directive in <stdin> - include::{noncompliant}[]

Instead, use another line to express the nested operation in a separate statement.

Unresolved directive in <stdin> - include::{compliant}[]

public String getReadableStatus(Job j) {
return j.isRunning() ? "Running" : j.hasErrors() ? "Failed" : "Succeeded";  // Noncompliant
}

Control structures should use curly braces

While not technically incorrect, the omission of curly braces can be misleading and may lead to the introduction of errors during maintenance.

Unresolved directive in <stdin> - include::{noncompliant}[]

Adding curly braces improves the code readability and its robustness:

Unresolved directive in <stdin> - include::{compliant}[]

The rule raises an issue when a control structure has no curly braces.

if (condition)  // Noncompliant
executeSomething();
checkSomething();

Two branches in a conditional structure should not have exactly the same implementation

Having two cases in a switch statement or two branches in an if chain with the same implementation is at best duplicate code, and at worst a coding error.

if (a >= 0 && a < 10) {
doFirstThing();
doTheThing();
}
else if (a >= 10 && a < 20) {
doTheOtherThing();
}
else if (a >= 20 && a < 50) {
doFirstThing();
doTheThing();  // Noncompliant; duplicates first condition
}
else {
doTheRest();
}

Get Started