# Search boxes and related items left out of the landmark list
Source: https://easeweb.dev/learn/region-purpose
Topics: Page structure > Icons, regions and controls can be swapped for symbols people know (WCAG 1.3.6)
The fix: Mark each area by what it is for. Either wrap the header's search form in a search element and move the related items out of main into an aside named by its heading, or, where the template's elements can't change, add role="search" to the form and role="complementary" to the related items' div, moved beside main.
Test with: screen reader, keyboard
References: https://www.w3.org/WAI/WCAG22/Understanding/identify-purpose.html https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA11 https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/ https://html.spec.whatwg.org/multipage/grouping-content.html#the-search-element https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/search https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/aside https://dequeuniversity.com/rules/axe/4.12/landmark-complementary-is-top-level https://skipto.disability.illinois.edu/skipto-extension/ https://www.w3.org/TR/adapt-symbols/
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.
## What happens
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.
## Why it fails
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 `form` with no name and no role. A `form` element 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 `div` inside `main`. 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](/learn/landmarks) 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.
## Who is affected
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.
## What automation and AI miss
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.
## Before: a plain search form, and related items inside main
```html
Enamel mug
$18
```
- 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 `div` inside `main`, 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.
## After: search and aside elements
```html
Enamel mug
$18
```
1. Wrap the search form in a `search` element. It is the search landmark, so the list shows "search" and choosing it lands on the box. The form inside needs no role.
2. Move the related items out of `main`, to sit beside it before the footer. Main now ends with the product.
3. Make their wrapper an `aside`, the complementary landmark, and name it with `aria-labelledby` pointing 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.
## After: search and complementary roles on the existing elements
```html
Enamel mug
$18
```
1. Add `role="search"` to the existing form. The form becomes the search landmark, with the same entry in the list as the element gives.
2. Move the related items' `div` out of `main`, beside it, as in the other fix.
3. Give the `div` `role="complementary"` and name it with `aria-labelledby` pointing at its heading.
The list reads exactly as with the elements, so this fixes the Before for its two regions and passes 1.3.6 for them (ARIA11). The roles say what each block is for only while they stay on the right elements: a form component that renders its own `form` has to pass `role` through to it, and the related items still have to leave `main`.
## Which option to use
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.
## Implementation decisions
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 `section` with 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](/learn/landmark-names) 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
1. In the browser's accessibility tree, or with a landmarks extension, list the page's landmarks: a search landmark holds the search form, a complementary landmark named "You may also like" holds the related items outside `main`, and `main` holds only the product.
2. Open a screen reader's landmark list (in NVDA, Insert + F7 and choose Landmarks; in VoiceOver, the rotor), or the menu of a landmark extension such as SkipTo. Check that the search and the related items each appear once in words that say what they are, then choose the search and check that it lands on the search box's area.
3. Read `main` from its start to its end, by moving to it and on with the landmark key (D in NVDA, R in JAWS), and check that it ends where the page's own content ends: no recommendations, promotions or recently viewed items inside it.
4. Repeat on each template (home, listing, product, article, checkout), with any search drawer open, since each template adds its own blocks around the content.
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](/learn/icon-buttons) shows. Fields that collect personal data identify their purpose through `autocomplete`, which [form fields that block or break autofill](/learn/autocomplete) 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](/learn/landmarks). Test the complete journey with your target assistive technology.
---
Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)