HTML Guides for list

The WAI-ARIA specification defines strict ownership requirements for certain roles. The listitem role is one such role — it must be “owned by” an element with role="list" or role="group". “Owned by” means the listitem must be either a direct DOM child of the owning element, or explicitly associated with it via the aria-owns attribute.

This matters because screen readers and other assistive technologies rely on the accessibility tree to convey structure to users. When a screen reader encounters a properly structured list, it announces something like “list, 3 items” and lets the user navigate between items. Without the parent role="list", the individual items lose their list context — users won’t know how many items exist, where the list begins and ends, or that the items are related at all.

In most cases, the simplest and most robust fix is to use native HTML list elements (<ul> or <ol> with <li> children) instead of ARIA roles. Native elements have built-in semantics that don’t require additional attributes. Only use ARIA roles when native elements aren’t feasible — for example, when building a custom component where the visual layout prevents using standard list markup.

Examples

Incorrect: listitem without a parent list

These listitem elements are not contained within a role="list" or role="group" parent, so the validator reports an error.

<div role="listitem">Apples</div>
<div role="listitem">Bananas</div>
<div role="listitem">Cherries</div>

Correct: wrapping items in role="list"

Adding a parent container with role="list" establishes the required ownership relationship.

<div role="list">
  <div role="listitem">Apples</div>
  <div role="listitem">Bananas</div>
  <div role="listitem">Cherries</div>
</div>

Correct: using native HTML list elements

Native <ul> and <li> elements implicitly carry the list and listitem roles without any ARIA attributes. This is the preferred approach.

<ul>
  <li>Apples</li>
  <li>Bananas</li>
  <li>Cherries</li>
</ul>

Correct: using role="group" for nested sublists

The role="group" container is appropriate for grouping a subset of list items within a larger list, such as a nested sublist.

<div role="list">
  <div role="listitem">Fruits
    <div role="group">
      <div role="listitem">Apples</div>
      <div role="listitem">Bananas</div>
    </div>
  </div>
  <div role="listitem">Vegetables
    <div role="group">
      <div role="listitem">Carrots</div>
      <div role="listitem">Peas</div>
    </div>
  </div>
</div>

Note that role="group" should itself be nested inside a role="list" — it doesn’t replace the top-level list container, but rather serves as an intermediate grouping mechanism within one.

Correct: using aria-owns for non-descendant ownership

If the DOM structure prevents you from nesting the items directly inside the list container, you can use aria-owns to establish the relationship programmatically.

<div role="list" aria-owns="item-1 item-2 item-3"></div>

<!-- These items live elsewhere in the DOM -->

<div role="listitem" id="item-1">Apples</div>
<div role="listitem" id="item-2">Bananas</div>
<div role="listitem" id="item-3">Cherries</div>

This approach should be used sparingly, as it can create confusion if the visual order doesn’t match the accessibility tree order. Whenever possible, restructure your HTML so the items are actual descendants of the list container.

Use a valid landmark or list role: remove role="list" from the section, or replace the element with a proper list (ul/ol) or a container that supports role="list".

The role attribute must use values allowed by ARIA for the given context. A section element is a landmark and must not be given role="list". If you intend to mark up a list of items, use semantic list elements: ul/ol with li. If you truly need ARIA list semantics (e.g., for custom components), use a neutral container (div) with role="list" and child elements with role="listitem". Prefer native HTML lists over ARIA roles because they provide built-in semantics and better accessibility. Examples:

• Native list: use ul + li.
• ARIA list (only if native markup isn’t possible): div role="list" containing div role="listitem".

HTML Examples

Example showing the validation error

<section role="list">
  <div>Item A</div>
  <div>Item B</div>
</section>

Fixed using native list semantics (recommended)

<ul>
  <li>Item A</li>
  <li>Item B</li>
</ul>

Fixed using ARIA roles on neutral elements (when custom UI prevents native lists)

<div role="list">
  <div role="listitem">Item A</div>
  <div role="listitem">Item B</div>
</div>

The HTML specification assigns implicit ARIA roles to many elements, meaning browsers and assistive technologies already understand their purpose without any extra attributes. The ul element has a built-in role of list, the nav element has a role of navigation, the button element has a role of button, and so on. When you explicitly add a role that matches the element’s implicit role, it creates redundancy that the validator warns about.

This principle is formalized as the first rule of ARIA use: do not use ARIA if a native HTML element already provides the semantics you need. Adding redundant ARIA roles clutters your markup, can confuse developers maintaining the code, and in rare edge cases may cause assistive technologies to announce information twice or behave unexpectedly.

This same warning applies to other elements with implicit roles, such as adding role="navigation" to a nav element, role="banner" to a header element, or role="contentinfo" to a footer element.

A note about Safari and list-style: none

There is one well-known exception worth mentioning. Safari intentionally removes list semantics from ul and ol elements when list-style: none is applied via CSS. This means VoiceOver on macOS and iOS will not announce the element as a list. In this specific case, some developers deliberately add role="list" to restore the list semantics. While the W3C validator will still flag it as redundant (since it evaluates HTML in isolation, without considering CSS), this is a legitimate accessibility pattern where the redundant role serves a real purpose. If you’re in this situation, you may choose to keep role="list" and accept the validator warning.

Examples

Incorrect: redundant role="list" on ul

<ul role="list">
  <li>Apples</li>
  <li>Bananas</li>
  <li>Cherries</li>
</ul>

Correct: relying on implicit semantics

<ul>
  <li>Apples</li>
  <li>Bananas</li>
  <li>Cherries</li>
</ul>

Incorrect: other common redundant roles

<nav role="navigation">
  <a href="/">Home</a>
  <a href="/about">About</a>
</nav>

<main role="main">
  <h1>Welcome</h1>
</main>

<footer role="contentinfo">
  <p>© 2024 Example Inc.</p>
</footer>

Correct: native elements without redundant roles

<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
</nav>

<main>
  <h1>Welcome</h1>
</main>

<footer>
  <p>© 2024 Example Inc.</p>
</footer>

Acceptable exception: restoring semantics removed by CSS

If your stylesheet strips list markers and you need to preserve list semantics for screen readers, the redundant role is a pragmatic choice:

<!-- list-style: none is applied via CSS, which removes semantics in Safari -->

<ul role="list" class="unstyled-list">
  <li>Step one</li>
  <li>Step two</li>
  <li>Step three</li>
</ul>

In this case, you can suppress or ignore the validator warning, understanding that it serves an accessibility need that the validator cannot detect from the HTML alone.