In Safari with VoiceOver, a menu marked up as a <ul> stops being announced as a list once CSS removes its bullets. Why does that happen, and what is the markup fix?

## The behaviour In WebKit, a list whose markers are removed via `list-style`/`list-style-type: none` is treated as presentational, and the `list` role is not exposed to VoiceOver. The user hears the links, but not "list, six items", not a position within the set, and not a boundary at the end. Nothing in the DOM changed — `document.querySelectorAll('li')` still finds every item — so the bug is invisible to markup review and to any test that inspects the DOM rather than the accessibility tree. The reasoning behind the decision is that authors overwhelmingly reach for `<ul>` as a generic repeating-container element and then strip the bullets, so verbose list announcements on every such block were judged to be noise. Whether you agree or not, the practical consequence is what matters in an interview: the pattern you almost certainly ship — a bulletless navigation list or card grid — is the exact pattern affected. ## The fix ```html <ul role="list" class="menu"> <li><a href="/">Home</a></li> <li><a href="/pricing">Pricing</a></li> </ul> ``` An explicit `role="list"` is authored intent rather than an inference, so the heuristic no longer applies and the list is exposed normally. The children are still `<li>` elements, so their `listitem` roles are intact and no per-item attribute is required in the ordinary case. ## Why this does not contradict "don't use ARIA when native works" The first rule of ARIA says to prefer a native element over role attributes — and this case does not violate it, because the native element is still doing the work. What you are adding is a repair: a redundant declaration that survives a stylesheet-driven downgrade. The distinction worth articulating is between **re-implementing** semantics with ARIA (`<div role="list">` with `<div role="listitem">` children, which you should not do) and **restoring** semantics on an element that already has them. Only the second is defensible, and only where a concrete browser behaviour makes it necessary. The alternative, of course, is to not suppress the markers — visually hiding them by other means, or accepting them. If a design genuinely has no markers, the explicit role is the cheaper answer than fighting the stylesheet. ## How to catch it This class of bug does not show up in the DOM, which is why teams miss it. It shows up in the accessibility tree — the browser's own accessibility inspector, or a screen-reader pass in the affected browser. Two practices help. First, put the repair in the shared component rather than at call sites: if your design system emits every menu, breadcrumb, and card grid from one list component, `role="list"` is added once. Second, treat the accessibility tree, not the DOM, as the artefact you review for semantics questions, because several browser behaviours — this one, elements hidden from the tree, roles altered by other display changes — are only visible there. ## Scope and honesty about the claim Be precise about the boundaries when you answer: this is a WebKit/VoiceOver behaviour tied to marker suppression, not a universal rule, and not something other engines are known to do in the same way. Do not generalise it into "CSS can strip any element's semantics" — the accurate statement is narrower and more useful: *some* browser behaviours mean the accessibility tree does not always mirror the markup one-to-one, so verifying semantics requires looking at the tree. ## The senior signal What an interviewer is listening for here is not the trivia. It is whether you know that markup semantics can be affected by rendering decisions at all, whether you can distinguish a legitimate ARIA repair from ARIA-as-reimplementation, and whether your instinct for verifying accessibility goes past "the element is correct in the DOM". A candidate who says "I would check the accessibility tree in that browser before assuming the markup is enough" has answered the real question even if they do not recall the specific behaviour.