In each set of pages, can the search engine be reached in an identical way?
A user with cognitive difficulties has memorized the location of the search field on your site. It is always in the top right. Except on the Shop page, where it has disappeared. He must now explore the entire page to find what he already knew how to use. An avoidable frustration.
Criterion 12.5 requires that the search engine be accessible in the same way on all pages of the same set. Three dimensions are checked: the mechanism (a form, not a link on some pages), the visual position, and the relative order in the source code. Do not surprise the user.
In practice, take two pages from the same template and compare them. Is the form present on both? In the same position on screen? In the same place in the DOM relative to other elements? If one answer is no, the criterion fails.
A "set of pages" refers to pages sharing the same template or the same navigation logic. A site with a customer area and a showcase site may constitute two distinct sets — each subject to its own internal consistency requirements.
3 tests to ensure that a search engine is available
Identical mechanism of access to search engine
- Open the developer tools (Elements tab) on the page being audited.
- Identify the mechanism for accessing the search engine:
<form>with<input type="search">, or<a>link to a search page, or other. - Open in the same way the generated source code of another page from the same set.
- Verify that the type of mechanism is identical on both pages (form on both, or link on both — not form on one and link on the other).
- Identical mechanism on both pages: test validated. Different type of access from one page to another: test not validated.
Identical visual position of search engine
- Display the page being audited in the browser.
- Note the visual position of the search engine in the layout (ex: header on right, sidebar, footer).
- Display another page from the same set.
- Verify that the search engine occupies the same visual position.
- Identical position on both pages: test validated. Visual shift observed: test not validated.
Identical DOM position of search engine
- Open the generated source code (developer tools) of the page being audited.
- Locate the relative position of the search engine in the DOM: does it appear before or after the main navigation? Before or after the
<main>? - Open the generated source code of another page from the same set.
- Verify that the relative order is identical (e.g.: always after
<nav>and before<main>). - Unchanged relative order: test validated. Different position in DOM from one page to another: test not validated.
Examples
❌ Non-compliant : Different access mechanism by page
<!-- Home page: search form in header -->
<header>
<nav aria-label="Main navigation"><!-- ... --></nav>
<form role="search" action="/results">
<label for="q-home">Search</label>
<input type="search" id="q-home" name="q">
<button type="submit">Launch</button>
</form>
</header>
<!-- Article page: form replaced by simple link -->
<header>
<nav aria-label="Main navigation"><!-- ... --></nav>
<a href="/search">Search the site</a>
</header>On the home page, the user interacts directly with an input field. On the article page, they find a link that takes them to another page before they can search. The mechanism has changed: test 12.5.1 fails. A screen reader user who navigates by the search landmark will find nothing on the article page, even though they found it without effort on the home page.
✅ Compliant : Consistent search form across all pages
<!-- Home page AND article page: identical structure -->
<header>
<nav aria-label="Main navigation"><!-- ... --></nav>
<form role="search" action="/results">
<label for="q">Search the site</label>
<input type="search" id="q" name="q">
<button type="submit">Launch search</button>
</form>
</header>The same form with the same role="search", in the same place in the DOM (after <nav>, in <header>), on all pages of the site. All three tests are satisfied: identical mechanism (12.5.1), constant visual position (12.5.2), unchanged DOM order (12.5.3). A user who learns how to find search no longer ever has to look for it.
Tips and pitfalls
⚠️ Form hidden on mobile breaks test 12.5.1
On some sites, the search <form> is present in the DOM on desktop but removed from the flow or replaced by a simple icon (without field) on mobile via JavaScript. Test 12.5.1 compares the source code generated client-side: if the mechanism changes based on screen size, the test fails. Systematically audit in responsive mode with the developer tools.
⚠️ Correct visual position, reversed DOM order
A form can appear in the same place visually thanks to CSS (flexbox with order, absolute position) while changing place in the DOM from one page to another. Test 12.5.2 would be validated, but 12.5.3 would fail. Screen reader users navigate by DOM order, not visual order — this is the most frequent error on this criterion in audits.
💡 Two search forms on each page: allowed
A form in the header and another in the footer are perfectly valid, as long as both are present on all pages of the set. If one disappears on certain pages, test 12.5.1 fails. Two forms performing the same global search can share the same aria-label.
⚠️ No search engine: criterion not applicable
Criterion 12.5 assumes a search engine is present on the site. If this is not the case, it is rated NA (not applicable) and does not affect the compliance rate. Do not confuse with criterion 12.6, which concerns quick access to navigation areas, of which the search engine is part if it exists.
⚠️ Pages outside set: template determines
Error 404 pages, order confirmation pages, or print pages may constitute a separate set if their template differs from the rest of the site. In an audit, clarify with the stakeholder which sets are within scope. Consistency requirements apply within each set, not between different sets.
Frequently asked questions
How to evaluate criterion 12.5 when the site does not have a search engine?
No. Without a search engine, criterion 12.5 is not applicable (NA). An NA criterion counts neither for nor against in the RGAA compliance rate calculation. Note it NA in your audit grid and move on to the next one.
What exactly does "same mechanism" mean for test 12.5.1?
The mechanism refers to the type of component used to access search. A <form> with <input type="search"> is one mechanism. An <a href="/search"> is another. If all pages of the same set use the same type, 12.5.1 is validated. If the type varies from one page to another (form here, link there), it fails. Content or style does not matter: only the type of access matters.
How to efficiently audit the three tests of criterion 12.5 in practice?
Open two pages from the same set in two tabs side by side. For 12.5.1 and 12.5.3, inspect the DOM in the developer tools and compare the structure around the search engine. For 12.5.2, a visual comparison is sufficient. Document with annotated screenshots for each discrepancy found.
In what case does removing the search engine constitute non-compliance with RGAA?
It depends on the definition of sets. If pages in the tunnel share the same template as the rest of the site, they are part of the same set and the criterion applies: removing search creates an inconsistency. If the tunnel has a distinct template (isolated interface), it constitutes its own set and the consistency rule applies only within this tunnel.
What is the difference between criterion 12.5 and criterion 12.6?
Criterion 12.5 concerns consistency: the search engine must be accessible in the same way on all pages of the same set. Criterion 12.6 concerns quick access: the search engine (and other areas) must be reachable directly, without traversing all content, via a skip link or a search landmark. Both can fail independently.