The listitem rule flags an <li> that is not directly inside a list – its parent is a <div>, a <nav>, or a <ul> whose role has been changed. Screen readers then cannot tell that the items belong together or how many there are. The fix is to put every <li> directly inside a <ul>, <ol> or <menu>.
What the rule means
An <li> is only a list item in relation to its list. The rule checks every <li> without a role attribute and looks at its direct parent. It passes when the parent has the role "list" – a <ul>, <ol> or <menu> without a role of its own, or any element with role="list" – or when the parent has role="none" or role="presentation".
It fails when the parent is any other element, or a list whose role has been replaced, such as <ul role="navigation"> or <ul role="menubar">. An <li> with its own role is skipped. Hidden elements are ignored.
listitem looks up from the item; its partner rule list looks down from the list. A wrapper <div> between <ul> and <li> fails both.
Who is affected
Blind and partially sighted people using a screen reader or a braille display. Inside a real list, the screen reader announces "list, 4 items" and can tell an item's position, such as "2 of 4" – orientation that sighted people get from bullets and spacing. An <li> without a list loses that: the items are read as loose lines, with no count and no clear end. In menus and breadcrumbs this makes it hard to judge how long the list is before deciding to skip it.
Why the check fails
- Partials rendered without their list: a breadcrumb or menu template outputs
<li>elements into a<div>or<nav>. - Replacing the role instead of wrapping:
<ul role="navigation">meant as a landmark, which removes the list the<li>needs. - ARIA menus and tab lists:
<ul role="menubar">orrole="tablist", with the<li>elements left at their default role. - Wrapper
<div>s from slider libraries or components between the<ul>and its items. - Copied snippets:
<li>elements pasted into a CMS text block without the surrounding list.
How to fix it
Give every <li> a list as its direct parent. For a landmark, wrap the list in <nav> rather than changing the list's role.
<!-- Before: items in a div, and a ul whose role was replaced -->
<div class="breadcrumb">
<li><a href="/">Home</a></li>
<li><a href="/shop/">Shop</a></li>
</div>
<ul class="main-menu" role="navigation">
<li><a href="/about/">About us</a></li>
</ul><!-- After: nav provides the landmark, the lists keep their list role -->
<nav class="breadcrumb" aria-label="Breadcrumb">
<ol>
<li><a href="/">Home</a></li>
<li><a href="/shop/">Shop</a></li>
</ol>
</nav>
<nav aria-label="Main menu">
<ul class="main-menu"><li><a href="/about/">About us</a></li></ul>
</nav>If you really build an ARIA menu bar – most site navigation should not be one – the <li> is only a wrapper and gets role="none":
<!-- An application-style menu bar: the li steps aside for the menuitem -->
<ul role="menubar" aria-label="Document actions">
<li role="none"><button type="button" role="menuitem">Save</button></li>
<li role="none"><button type="button" role="menuitem">Print</button></li>
</ul>How to test it manually
- In the browser's developer tools, select an
<li>and open the accessibility pane: its role should be "listitem", and its parent's role "list". - With a screen reader, move through the menu or breadcrumb. Do you hear the list and its number of items?
- Check navigation, breadcrumbs, footers and tag lists in particular – they are where
<li>elements most often lose their list. - The rule sees only
<li>elements. It cannot tell whether a group of<div>s or links that looks like a list should be one; that is a manual check.
Related WCAG criterion
1.3.1 Info and Relationships, Level A: the grouping people see has to be in the markup. Related: 4.1.2 Name, Role, Value, for ARIA widgets such as menus, where every part needs the role the pattern expects.
How Reviseberg reports it
Reviseberg runs listitem on every crawled page. Each <li> without a proper parent is one occurrence, so one broken menu template with six items appears six times on every page. The issue list shows the rule with its severity, WCAG 1.3.1 at Level A, the number of elements and pages, and the points a fix gets you back – the ranking makes a template-wide fix visible at a glance. The detail view shows the selector and HTML snippet of each item and every affected page. You can mark a finding as "ignore", "can't fix" or "false positive" with a reason; every decision is logged.
A clean result on this rule does not make 1.3.1 a pass on its own: the criterion is only partly covered by automated checks, and the rest needs a person.