In each form, is each label associated with a form field that has the same function and is repeated several times on the same page or across a set of pages consistent?
A user navigates an e-commerce website. On the homepage, the search field is called "Search". On the category page, it reads "Find". On the results page, "Look for". For a person with cognitive disabilities, or for a screen reader user who identifies forms by their labels, this variability creates real mental strain: is this the same tool or different functions?
Criterion 11.3 requires that fields with the same function bear consistent labels, whether within the same page or across a set of pages. Consistency does not require perfect identity, but labels must allow users to understand they are the same type of input. An order form with two address blocks must name its street fields the same way in both blocks.
Same function, same label. That's the rule.
This problem arises in two concrete situations. Multi-section forms built by different developers without coordination: one names the field "Address", another "Street". A/B tests or duplicated components that evolve independently from page to page. The most reliable solution: a reusable component with a fixed label.
2 tests to verify the consistency of labels across pages
Consistency of labels of same nature in page
- Identify groups of fields with the same function within the page (e.g.: two address blocks in an order form, multiple email fields in a multi-step form).
- For each group, compare the labels used: do they allow understanding that these are the same type of input?
- If one label says "Address" and another says "Street" for two street fields, the test fails.
- If all labels are consistent with each other, the test is validated.
Consistency of labels of same nature between pages
- Across all pages in the audit sample, identify recurring fields: global search field, newsletter signup, login form.
- For each recurring field, note the label used on each page where it appears.
- Compare the labels across pages: are they identical or close enough that a user understands these are the same field?
- If a variation exists (e.g.: "Search" on one page, "Find" on another), the test fails.
- If all labels are consistent across all pages, the test is validated.
Examples
❌ Non-compliant : Two address blocks with inconsistent labels
<fieldset>
<legend>Billing Address</legend>
<label for="fact-adresse">Address</label>
<input type="text" id="fact-adresse" name="fact_adresse">
<label for="fact-cp">Postal Code</label>
<input type="text" id="fact-cp" name="fact_cp">
<label for="fact-ville">City</label>
<input type="text" id="fact-ville" name="fact_ville">
</fieldset>
<fieldset>
<legend>Delivery Address</legend>
<label for="livr-rue">Street</label>
<input type="text" id="livr-rue" name="livr_rue">
<label for="livr-cp">Postal Code</label>
<input type="text" id="livr-cp" name="livr_cp">
<label for="livr-ville">City</label>
<input type="text" id="livr-ville" name="livr_ville">
</fieldset>The first street field is called "Address", the second "Street". For a screen reader user navigating by form, or for a person with cognitive difficulties, this inconsistency creates doubt: do these two fields really ask for the same thing? Test 11.3.1 fails.
✅ Compliant : Two address blocks with consistent labels
<fieldset>
<legend>Billing Address</legend>
<label for="fact-rue">Street</label>
<input type="text" id="fact-rue" name="fact_rue">
<label for="fact-cp">Postal Code</label>
<input type="text" id="fact-cp" name="fact_cp">
<label for="fact-ville">City</label>
<input type="text" id="fact-ville" name="fact_ville">
</fieldset>
<fieldset>
<legend>Delivery Address</legend>
<label for="livr-rue">Street</label>
<input type="text" id="livr-rue" name="livr_rue">
<label for="livr-cp">Postal Code</label>
<input type="text" id="livr-cp" name="livr_cp">
<label for="livr-ville">City</label>
<input type="text" id="livr-ville" name="livr_ville">
</fieldset>Both blocks use exactly the same labels ("Street", "Postal Code", "City"). The fieldset legend ("Billing Address" / "Delivery Address") differentiates the context without changing the field labels. The user immediately understands they are entering the same type of information in both blocks.
Tips and pitfalls
⚠️ Synonyms cause test failure
"Search", "Find", "Look for": to a developer, these are equivalent variants. For criterion 11.3 and failure technique F31, these are three different labels for the same function. The test fails. Choose a term and stick to it across all pages.
⚠️ Same input format does not mean same function
A "Billing email" field and a "Delivery email" field have the same format, but different functions. Criterion 11.3 does not apply between them. It applies if the same "Email" field appears in the registration form across multiple pages with varying labels.
💡 A reusable component structurally guarantees consistency
If your search field is a React, Vue, or Web Component with a label defined in the component itself, inter-page consistency is guaranteed without effort. It's more reliable than a documented naming convention that each developer must manually follow.
⚠️ A/B tests silently break consistency
An interface test that renames a field on a variant creates non-compliance with criterion 11.3 if both variants coexist at the same time on different pages. This is a frequent error during audits of sites with personalization or experimentation tools active.
⚠️ Consistency does not require perfect identity
The criterion requires that labels allow you to "understand that these are inputs of identical natures". "Email" and "Email address" for the same login field are generally considered consistent. In contrast, "Username" and "Login" for the same field constitute real ambiguity depending on the target audience.
Frequently asked questions
How to audit consistency across a set of pages in practice?
Build a table: each row is a recurring field (search, newsletter, login), each column is a page in the sample. Enter the label found on each page. Cells that differ signal non-conformities. For a standard-sized website, the task takes around twenty minutes.
When does a variation like Email and Email address constitute a non-compliance with RGAA 11.3?
Not in most cases. The criterion evaluates whether the user can understand they are the same type of input: "Email" and "Email address" are close enough. In contrast, "Search" and "Find" for the same field constitute an inconsistency under the criterion and failure technique F31.
In which cases does RGAA criterion 11.3 concern submit buttons?
When do different labels on the same recurring search field constitute a non-compliance with RGAA?
Yes. If both fields are present on the same page with different labels, this is a non-compliance with test 11.3.1. If labels vary only between pages, test 11.3.2 applies. In both cases, the fix is the same: a single, systematic label, carried by a shared component.