> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Common

<AccordionGroup>
  <Accordion title="Non-interactive DOM elements should not have the `tabIndex` property">
    <div class="paragraph">
      <p>The misuse of the tabIndex attribute can lead to several issues:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>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.</p>
        </li>

        <li>
          <p>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.</p>
        </li>

        <li>
          <p>Increased Tab Ring Size: It unnecessarily increases the size of the page’s tab ring, making navigation more cumbersome.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      <div tabIndex="0" />
      ```

      ```common Fix theme={null}
      <div />
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Label elements should have a text label and an associated control">
    <div class="paragraph">
      <p>When a label element lacks a text label or an associated control, it can lead to several issues:</p>
    </div>

    <div class="olist arabic">
      <ol class="arabic">
        <li>
          <p><strong>Poor Accessibility</strong>: 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.</p>
        </li>

        <li>
          <p><strong>Confusing User Interface</strong>: 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.</p>
        </li>

        <li>
          <p><strong>Code Maintainability</strong>: 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.</p>
        </li>
      </ol>
    </div>

    <div class="paragraph">
      Control elements are:

      * \`\<input>
      * \<meter>
      * \<output>
      * \<progress>
      * \<select>
      * \<textarea>\`
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```common Bad theme={null}
      <input type="text" />
      <label>Favorite food</label>
      ```

      ```common Fix theme={null}
      <label>
      <input type="text" />
      Favorite food
      </label>
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Anchors should contain accessible content">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      <a aria-hidden>link to my site</a>
      ```

      ```common Fix theme={null}
      <a>link to my site</a>
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Focusable elements should not have aria-hidden attribute">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>This rule ensures that focusable elements are not hidden from screen readers using the aria-hidden attribute.</p>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      <button aria-hidden="true">Click me</button>
      ```

      ```common Fix theme={null}
      <button>Click me</button>
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Elements with an interactive role should support focus">
    <div class="paragraph">
      <p>Lack of focusability can hinder navigation and interaction with the website, resulting in an exclusionary user experience and possible violation of accessibility guidelines.</p>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      <!-- 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>
      ```

      ```common Fix theme={null}
      <!-- Element with mouse handler has tabIndex -->
      <span onClick="doSomething();" tabIndex="0" role="button">Submit</span>

      <!-- Focusable anchor with mouse handler -->
      <a href="javascript:void(0);" onClick="doSomething();"> Next page </a>
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Statements should be on separate lines">
    <div class="paragraph">
      <p>Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.</p>
    </div>

    <div class="paragraph">
      <p>Unresolved directive in \<stdin> - include::\{noncompliant}\[]</p>
    </div>

    <div class="paragraph">
      <p>Write one statement per line to improve readability.</p>
    </div>

    <div class="paragraph">
      <p>Unresolved directive in \<stdin> - include::\{compliant}\[]</p>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      if (someCondition) doSomething(); // Noncompliant
      ```

      ```common Fix theme={null}
      if (someCondition) {
      doSomething();
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Ternary operators should not be nested">
    <div class="paragraph">
      <p>Nested ternaries are hard to read and can make the order of operations complex to understand.</p>
    </div>

    <div class="paragraph">
      <p>Unresolved directive in \<stdin> - include::\{noncompliant}\[]</p>
    </div>

    <div class="paragraph">
      <p>Instead, use another line to express the nested operation in a separate statement.</p>
    </div>

    <div class="paragraph">
      <p>Unresolved directive in \<stdin> - include::\{compliant}\[]</p>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      public String getReadableStatus(Job j) {
      return j.isRunning() ? "Running" : j.hasErrors() ? "Failed" : "Succeeded";  // Noncompliant
      }
      ```

      ```common Fix theme={null}
      public String getReadableStatus(Job j) {
      if (j.isRunning()) {
      return "Running";
      }
      return j.hasErrors() ? "Failed" : "Succeeded";
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Control structures should use curly braces">
    <div class="paragraph">
      <p>While not technically incorrect, the omission of curly braces can be misleading and may lead to the introduction of errors during maintenance.</p>
    </div>

    <div class="paragraph">
      <p>Unresolved directive in \<stdin> - include::\{noncompliant}\[]</p>
    </div>

    <div class="paragraph">
      <p>Adding curly braces improves the code readability and its robustness:</p>
    </div>

    <div class="paragraph">
      <p>Unresolved directive in \<stdin> - include::\{compliant}\[]</p>
    </div>

    <div class="paragraph">
      <p>The rule raises an issue when a control structure has no curly braces.</p>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      if (condition)  // Noncompliant
      executeSomething();
      checkSomething();
      ```

      ```common Fix theme={null}
      if (condition) {
      executeSomething();
      checkSomething();
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Two branches in a conditional structure should not have exactly the same implementation">
    <div class="paragraph">
      <p>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.</p>
    </div>

    <CodeGroup>
      ```common Bad theme={null}
      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();
      }
      ```

      ```common Fix theme={null}
      if ((a >= 0 && a < 10) || (a >= 20 && a < 50)) { // Compliant
      doFirstThing();
      doTheThing();
      }
      else if (a >= 10 && a < 20) {
      doTheOtherThing();
      }
      else {
      doTheRest();
      }
      ```
    </CodeGroup>
  </Accordion>
</AccordionGroup>