What does the "list" or "listitem" accessibility error mean?

It means a list on the page is built with the wrong markup. The "list" error flags an unordered or ordered list (ul or ol) that contains something other than list items. The "listitem" error flags an li that is not inside a ul or ol. Both break the structure a screen reader uses to announce "list, 5 items" and to let users navigate by list. WCAG Success Criterion 1.3.1 (Level A) requires that structure like this be available in the markup, not just visually.

Why use a real list instead of divs?

A screen reader announces a real ul or ol as "list, N items" and lets the user jump from list to list and item to item. A set of divs styled to look like a list conveys none of that - the user hears the items as loose, unrelated lines with no sense of how many there are or where the group begins and ends. The visual list and the programmatic list have to match.

Does broken list markup fail WCAG?

Yes. A list whose structure is only visual, not in the markup, fails Success Criterion 1.3.1 Info and Relationships at Level A. An automated scanner is reliable here, because list and listitem are structural rules: it can tell when an li sits outside a list or a ul holds the wrong children. The judgment left to a person is whether a group of items should be a list at all.

How do I make an accessible navigation menu?

Mark the set of links up as a list: a ul with one li per link, each li containing an anchor. Use CSS (list-style: none and flex or grid) to make it look like a horizontal bar or a grid of cards - the styling does not change the semantics. The screen reader still announces it as a list with a known number of items, which helps users understand and move through the navigation.

Broken List Structure: What It Means and How to Fix It

By Site Brace Research · Published June 15, 2026

A broken list is a list that looks like one on screen but is not marked up as one in the code, so a screen reader cannot announce it as a list. Navigation menus, footer links, and card grids are the usual places it happens - built from <div>s, or with list items floating outside any list. WCAG Success Criterion 1.3.1 (Level A) requires that this kind of structure live in the markup, not just in the visual styling. We found it on the home pages of large US sites in our 2026 scan: list-structure errors on 25 of the 299 pages, plus list items placed outside a list on another 16. The fix is the original HTML it should have been: a <ul> or <ol> with <li> items, styled with CSS.

A real list does two quiet but important things for a screen reader user. It announces "list, five items" when they arrive, so they know how much is there and that the items belong together. And it lets them move through it - item to item, or skip the whole list - with a keystroke. A pile of <div>s that merely looks like a list does neither. The user hears five disconnected lines and never learns they were a set. This page covers what the list and listitem errors mean, who they affect, how common they are, and how to fix each version.

What "broken list structure" means

WCAG Success Criterion 1.3.1 Info and Relationships, at Level A, requires that "information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text." A list is exactly that kind of structure: the bullets and indentation a sighted user sees have to be encoded in the markup so a screen reader can convey the same grouping.

Automated tools check this with two rules:

Rule	What it flags
`list`	A `<ul>` or `<ol>` that contains something other than list items (for example a `<div>` dropped directly inside it)
`listitem`	An `<li>` that is not inside a `<ul>` or `<ol>`, so it has no list to belong to

Both come down to the same thing: the list a person sees and the list the browser exposes to assistive technology have drifted apart.

Who this shuts out

Screen reader users, who lose two things: the "list of N items" announcement that tells them how much is there, and the ability to navigate by list. Without it, a navigation menu is just a run of links with no edges.
People who rely on structure to understand a page - the grouping a list conveys is part of how content is organized, and that organization helps comprehension for many users, not only screen reader users.

How common is it?

In our State of Web Accessibility 2026 study of 299 large US home pages, the list rule failed on 25 of them (8%), and the related listitem rule on 16 more. It showed up most on government, higher-education, and nonprofit home pages - the sites with dense navigation: mega-menus, directories of services, and grids of program or article cards, which are exactly the components developers tend to build out of <div>s and forget to mark up as lists.

The usual culprits

Navigation and mega-menus built from nested <div>s instead of a <ul> of links.
Footer link columns and card grids that are visually a list but coded as a stack of <div>s.
A <ul> with the wrong children - a <div> wrapper dropped directly inside the <ul>, between it and its <li>s.
Stray <li>s left outside any <ul> or <ol> after a refactor.

<!-- Broken: looks like a menu, announces nothing -->
<div class="nav">
  <div>Home</div>
  <div>Products</div>
  <div>Pricing</div>
</div>

<!-- Fixed: announced as "list, 3 items", styled with CSS -->
<ul class="nav">
  <li><a href="/">Home</a></li>
  <li><a href="/products">Products</a></li>
  <li><a href="/pricing">Pricing</a></li>
</ul>

How to fix it

Find the broken lists. Run a scan or use axe DevTools to surface every list and listitem failure.
Use <ul> or <ol> for any group of related items - navigation, footer links, card sets, steps.
Put only <li>s directly inside the list. Move wrapper <div>s and content inside the <li>, not between the <ul> and its items.
Never leave an <li> outside a list. Wrap stray items in a <ul>, or use a different element if they are not really a list.
Style with CSS, not markup. list-style: none plus flex or grid makes a list look like a bar or a card grid without dropping the semantics.
Re-test by listening. Re-scan, then confirm with a screen reader that each list announces as a list with the right number of items.

What a scan can and cannot tell you

This is one of the failures an automated scan handles well. list and listitem are structural facts about the markup, so a scanner finds them reliably and points at the exact element. The judgment left to a person is the design question underneath: is this group of items actually a list? Usually the answer is obvious - a menu, a set of cards, a directory. We test that automated slice and report it; the design call is part of a full audit.

Common questions

What does the "list" or "listitem" error mean? A list is built with the wrong markup - a <ul>/<ol> holding non-list-item children, or an <li> outside any list - so a screen reader cannot announce it as a list.

Why a real list instead of divs? A real list is announced as "list, N items" and can be navigated as a unit; divs convey none of that.

Does it fail WCAG? A visual-only list fails 1.3.1 (Level A).

How do I make an accessible menu? Use a <ul> of <li> links and style it with CSS; the look changes, the semantics stay.

Check your own site

Run a free check on your home page to see every broken list, with the element to fix, in about a minute. For the whole site, see what a full audit covers, and how monitoring catches the menus and card grids that lose their list markup whenever a component is rebuilt. For the data behind this page, read the State of Web Accessibility 2026; its companion failures are low color contrast, links without discernible text, and missing alt text.