Search topics
Search boxes and related items left out of the landmark list
A shop's header search is a plain form and its "You may also like" panel sits inside main, so the landmark list has no search and counts the panel as content.
<form action="/search"> The problem
People who find their way around a page by its areas can't go straight to the search, or tell the shop's suggestions from the product
A homeware shop's product page has the shape most shops share. The header holds the logo, Tidewater Home, a menu of three links and a search box. Under it is the product, an enamel mug at $18, then a row of other products under the heading "You may also like", and a footer with Contact and Returns. The page's shell is built well: the header, the menu, the content and the footer are landmarks, so a landmark list reads "banner", "navigation", "main", "content information", and nothing sits outside them.
Someone who finds their way around pages by their areas opens that list, from a screen reader or from a landmark extension such as SkipTo, to go to the search. There is no search in it. They can choose the banner and look through the header for the box, or press Tab through the logo and the menu until they reach it. Then they choose main to read about the mug, and the list's main takes in "You may also like" as well, as if the other products were part of the mug's page. Nothing in the list says which part of main is the product and which is the shop's suggestions.
1.3.6 asks that the purpose of each region on a page can be programmatically determined: that the code says what each area is for, not only how it looks. The Understanding page gives the reason: "Identifying regions of the page allows people to remove or highlight regions with their user agent." Its first example is a site whose landmarks let users "hide areas that do not have a role of main". The sufficient technique for regions is ARIA11, landmarks, and its list of landmarks includes a search landmark for the search and a complementary landmark for content that supports the main content but stands on its own.
This page uses landmarks for its shell and stops there:
- The search is a
formwith no name and no role. Aformelement becomes a landmark only when it has a name, and then it is a "form", not a "search". So no landmark in the code says where the search is, and tools that list a page's regions leave it out. - The related items are a
divinsidemain. The code says they are the main content, the reason the page exists, so a tool that keeps main and hides everything else keeps them.
The page has what landmarks that are missing, misplaced or leave content out asks for under 1.3.1: its four areas are landmarks and all its content sits inside one. 1.3.6 asks for more, the purpose of the page's regions, and here two regions a visitor would name, the search and the suggestions, have no purpose of their own in the code. WCAG lists no failure technique for 1.3.6, and ARIA11's test examines the landmarks a page has, not the ones it lacks, so which regions need one is a judgement made from the criterion's wording and examples. It is AAA, so few audits ask for it.
Both areas look the way a visitor expects, a search box at the top and a row of products under a heading. What fails is only what the code says about them, and it repeats on every page that shares the header and the product template.
2 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities Landmark menus, such as the SkipTo and Landmarks browser extensions, list a page's areas in a few words and jump to the one chosen, a short way through a busy page. Here the menu has no search, and the suggestions are counted as part of the product, so a tool that keeps the main content and hides the rest, as 1.3.6 imagines, would keep them too.
- Without vision Screen reader users press the landmark key, or open the landmark list, to reach the search without reading the header. On this page the list has no search, so they look for the field another way, such as the key that moves between form fields.
axe has no rule for 1.3.6: its three AAA rules cover contrast (1.4.6), link purpose (2.4.9) and page refreshes (2.2.4 and 3.2.5). Its landmark rules pass this page, since it has one main, one banner and one content information landmark, and nothing outside them. This audit raises each search box with no search landmark around it as a lead for review, with the field's name and its button's words, since a search box outside a search landmark can be found from the code. It can't say whether a block is related content that stands apart or part of what the page is for: a product's reviews and size guide belong in main, its recommendations don't, and the code gives no sign of the difference. That takes a person reading the page. AI tools asked to add landmarks tend to add too many: role="search" on a newsletter sign-up, an aside around the product's own details, or a named section around every block, which fills the landmark list with areas nobody wants to jump to.
Try it
Use the landmark tool to jump to the search, then show only the main content
The bar above the window stands in for tools that read a page’s landmarks. Jump to lists them, as the SkipTo extension does, and Show only the main content hides everything else, the example the WCAG Understanding page gives for 1.3.6. Is the search in the menu? With only the main content shown, what is still there besides the mug? Then apply a fix and try both again.
The fix
Mark the search and the related items as landmarks
<header> <a href="/" class="logo">Tidewater Home</a> <nav> <a href="/kitchen">Kitchen</a> <a href="/table">Table</a> <a href="/bath">Bath</a> </nav> <form action="/search"> <label for="q" class="visually-hidden">Search the shop</label> <input id="q" name="q" type="search"> <button type="submit">Search</button> </form></header><main> <h1>Enamel mug</h1> <p class="price">$18</p> <div class="related"> <h2>You may also like</h2> <ul>…</ul> </div></main><footer> <a href="/contact">Contact</a> <a href="/returns">Returns</a></footer>What is wrong3 points
- The search form has no role and no name, so it is not a landmark, and the landmark list has no search.
- The related items are a
divinsidemain, so the code counts them as the product page's own content. - So the list reads "banner", "navigation", "main", "content information", and neither the search nor the suggestions can be reached, kept or hidden by what they are.
Search and aside elements
<header> <a href="/" class="logo">Tidewater Home</a> <nav> <a href="/kitchen">Kitchen</a> <a href="/table">Table</a> <a href="/bath">Bath</a> </nav> <search> <form action="/search"> <label for="q" class="visually-hidden">Search the shop</label> <input id="q" name="q" type="search"> <button type="submit">Search</button> </form> </search></header><main> <h1>Enamel mug</h1> <p class="price">$18</p></main><aside class="related" aria-labelledby="related-title"> <h2 id="related-title">You may also like</h2> <ul>…</ul></aside><footer> <a href="/contact">Contact</a> <a href="/returns">Returns</a></footer>How it is fixed3 steps
- Wrap the search form in a
searchelement. It is the search landmark, so the list shows "search" and choosing it lands on the box. The form inside needs no role. - Move the related items out of
main, to sit beside it before the footer. Main now ends with the product. - Make their wrapper an
aside, the complementary landmark, and name it witharia-labelledbypointing at its heading, so the list says "You may also like" with it.
The landmark list now reads "banner", "navigation", "search", "main", "complementary, You may also like", "content information", and main holds only the mug. This fixes the Before for its two regions and passes 1.3.6 for them; icons and controls are the rest of the criterion (see Limits). The aside can keep the look the div had: the layout places it under the product with CSS, wherever it sits in the markup.
Why this fix: Use native HTML first
Both give the same landmark list and meet 1.3.6 for these regions. Use the elements: search and aside do the same job as the roles with no attribute to keep in step, and the search element has worked across browsers since October 2023. Keep the roles for a template whose elements you can't change, such as a form component that renders its own form and passes attributes through, and switch when you can.
Decide what belongs in main by asking what the page is for. A product page is for the product: its photos, price, options, description, reviews and size guide stay in main. Blocks the shop adds around it go beside main.
- Recommendations, recently viewed items and "complete the look" rows are complementary: related to the product, but still meaningful on their own.
- A newsletter sign-up or a promotion that has nothing to do with the product is not complementary. The ARIA Authoring Practices suggest a more general landmark for unrelated content: a
sectionwith a name, which is a region. - When there are two complementary blocks, such as recommendations and recently viewed, each needs its own name, as navigation landmarks that all sound the same explains.
Put the aside beside main, not inside it. The ARIA Authoring Practices say complementary landmarks should be top-level, and a tool that keeps main and hides the rest can only hide what is outside main. axe's rule for this, landmark-complementary-is-top-level, is now deprecated and off by default, because the ARIA 1.3 draft lets a complementary landmark sit directly inside the main content it supports. Beside main suits both the Authoring Practices and the draft. A theme that renders every section inside main needs a place in its layout, beside main, for the blocks that move.
Use the search landmark for search and filtering only. The HTML standard's search element is for "a search or filtering operation", so a filter form above a product list can be one too, and a search on a page of its own gets one as much as the header's. A sign-in form or a newsletter form with a single text field is not a search. When a search opens in a drawer or a dialog, put the search element around the form inside it; when a page has two searches, name each one.
An article's own aside, such as a pull quote inside an article, is not a complementary landmark unless it has a name, which is right for a quote. Use aside for the page's related content, not for every box with a border.
Verify the fix
4 checks, no mouse.
Test with: Screen reader, Keyboard
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat whenever a template gains a new block.
Limits
This is a starting pattern, not a guarantee for every application. Paths, class names and the … in the lists are placeholders, and screen readers word landmarks differently (NVDA, for one, says "content info" for what this guide calls "content information"), so listen for the areas rather than the exact phrasing. This guide covers regions, one of the three things 1.3.6 names. Icons and controls are the others, and WCAG has no published technique for them yet: its Understanding page lists one for controls, using microdata, as a future link. The W3C's attribute for marking a word or a picture with a symbol concept, adapt-symbol in the WAI-Adapt Symbols Module, has been a Candidate Recommendation since January 2023, and it needs two user agents or extensions that act on it before it can move on. Its implementation report names no browser or extension that does, so a page can't count on icons being swapped for a person's own symbols today. What a tool can read from an icon or a control now is its name, so give each one, as icon-only buttons with no accessible name shows. Fields that collect personal data identify their purpose through autocomplete, which form fields that block or break autofill covers. The shell's own landmarks, one main and a header and footer at the top level, are in landmarks that are missing, misplaced or leave content out. Test the complete journey with your target assistive technology.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: identify-purpose (opens in a new tab)
- WCAG Technique ARIA11 (opens in a new tab)
- ARIA APG: landmark-regions (opens in a new tab)
- html.spec.whatwg.org: grouping-content (opens in a new tab)
- developer.mozilla.org: search (opens in a new tab)
- developer.mozilla.org: aside (opens in a new tab)
- dequeuniversity.com: landmark-complementary-is-top-level (opens in a new tab)
- skipto.disability.illinois.edu: skipto-extension (opens in a new tab)
- w3.org: adapt-symbols (opens in a new tab)
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.