In one paragraph
LI elements must be contained in a UL or OL means the tested item lacks a parent relationship accepted by the list-item rule. Ordinary items should belong to an appropriate native list, including menu where its HTML semantics fit. Remove accidental wrappers or choose other markup for non-list content. Do not add arbitrary roles merely to evade a structural warning without preserving the intended user experience.
Why it matters
A list groups related items so people and software can understand membership and order. Ordered steps and unordered navigation need different meanings, but both depend on coherent parent-child structure. A visual bullet does not repair an orphaned list item.
The HTML menu element can also contain list items. ARIA application menus are a different concept from ordinary site navigation: declaring a menu or tablist changes expected child roles and keyboard interaction. A website navigation list does not need an application-menu role just because a designer calls it a menu.
HTML validity and one automated rule are not the same test. A custom role path may satisfy an accessibility checker without making arbitrary native-element nesting valid or the widget behaviour complete.
How WebAuditOS evaluates this finding
The supplied listitem rule examines applicable visible li elements without an overriding role and evaluates their immediate parent. Its documented accepted paths include native list containers and specific ARIA or presentation cases. A wrapper between an ordinary list and item can therefore trigger both this rule and the parent-list rule.
Serious impact maps to high severity. An overridden li can leave this rule's scope while requiring other ARIA checks. Exact applicability should be confirmed for the deployed version; no reported violation is not certification of all list or widget semantics.
How to fix it
- Inspect the rendered item's immediate parent and the intended grouping. Framework component wrappers, CMS menu walkers, and third-party libraries can differ from what template indentation suggests.
- For a normal collection of links, use native list markup. For example:
<nav aria-label="Main"><ul><li><a href="/">Home</a></li><li><a href="/pricing">Pricing</a></li></ul></nav>The example expresses a navigation list, not an application menu requiring arrow-key interaction.
- Remove unnecessary layout wrappers between ul or ol and li. Move classes to the list or wrap the whole list externally. Item components can return the li itself instead of another enclosing div.
- Nest sublists inside an li of the parent list, not directly beside its items. Ensure the hierarchy reflects real relationships and remains understandable when CSS is unavailable.
- If a true ARIA widget is intended, implement its complete roles, states, and keyboard model. A li given menuitem merely to suppress this warning is not a finished application menu.
- If the content is not a list, replace li with an appropriate element rather than forcing a misleading list wrapper. Do not choose semantic elements solely for default indentation or styling.
- Update direct-child CSS and scripts that depend on the old container. Test visual order, keyboard navigation, responsive presentation, and dynamic insertion or removal of items.
- Rescan both list-item and parent-list checks, and inspect manual accessibility output. Test all intended component states rather than only an initial populated navigation.
What the fix can break
Changing the parent can introduce native padding and markers or affect flex and grid rules. Preserve the intended appearance deliberately without deleting useful semantic grouping.
Removing a custom widget role can alter keyboard assumptions in existing scripts. Evaluate whether the old behaviour was appropriate and implement the intended pattern consistently.
Do not use role=presentation as a universal escape hatch. A cleaner report should not come at the cost of losing needed relationships or discoverability.
Questions
Is menu a valid native parent for li?
Yes, HTML defines that relationship. Do not confuse it with an ARIA menu widget implementation.
Why do two list findings appear together?
One intervening wrapper can be invalid from both the parent's and the item's perspective. Repair the structure rather than hiding one side.
Do added roles prove the HTML is valid?
No. Role applicability and HTML content models require separate consideration.
Which related checks help?
Review parent-list structure, description-list items, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core 4.13.0, so a failure arrives as high - which is why the panel above states a conformance level rather than a severity.