In each form, is the label of each button relevant (except in special cases)?
A screen reader user navigates from button to button using the keyboard. If five forms each display a button labeled "Submit", they don't know which one subscribes to the newsletter and which one deletes the account. A vague label means an unknown action.
This criterion covers two distinct obligations. The first (test 11.9.1): the visible label and the accessible name must be relevant, meaning they must allow understanding the button's function without additional context. The second (test 11.9.2): the accessible name must contain the visible label. This rule protects users of voice command software like Dragon: if the button displays "Search" but its accessible name is "Launch the search", the command "Click Search" fails silently.
Concerned elements: <input type="submit">, <input type="reset">, <input type="image">, <input type="button">, <button> regardless of its type, and any element bearing role="button". The accessible name is calculated in this order: aria-labelledby, then aria-label, then the text content for <button>, then the value attribute for <input>, finally the title attribute as a last resort.
2 tests to verify that each button has an explicit label
Relevance of visible label and accessible name of button
For each button present in a form:
- Identify the visible label (text displayed on screen, or the value of the
altattribute for<input type="image">). - Calculate the accessible name: inspect in order
aria-labelledby,aria-label, text content of the<button>,valueattribute,titleattribute. - Verify that the visible label is relevant: it must allow understanding the button's function without relying on the surrounding context.
- Verify that the accessible name is relevant using the same criteria.
- If either is not relevant for at least one button, the test fails.
Accessible name of button containing visible label
For each button present in a form:
- Note the visible label of the button (the text displayed on screen).
- Calculate its accessible name (see test 11.9.1 for the calculation order).
- Verify that the accessible name fully contains the text of the visible label (the comparison is case-insensitive).
- If the accessible name does not contain the visible label for at least one button, the test fails.
Note: this test does not apply to buttons without a visible text label (icon-only buttons). Consult the special cases of criterion 11.2 for specific configurations related to
aria-labelledby.
Examples
❌ Non-compliant : Generic button without informative value
<form>
<h2>Account deletion</h2>
<p>This action is irreversible.</p>
<button type="submit">OK</button>
</form>"OK" does not indicate the button's function. A screen reader user navigating by buttons hears "OK, button" without understanding that they are about to delete their account. Test 11.9.1 failed.
❌ Non-compliant : aria-label that overrides visible text without containing it
<form>
<label for="email">Email address</label>
<input type="email" id="email" name="email">
<button type="submit" aria-label="Launch registration">Sign up</button>
</form>The visible label is "Sign up", but the calculated accessible name is "Launch registration". This name does not contain the visible text. A Dragon user who says "Click Sign up" will not trigger the button. Test 11.9.2 failed.
✅ Compliant : Icon-only button with relevant accessible name
<form>
<label for="q">Search</label>
<input type="text" id="q" name="q">
<button type="submit" aria-label="Search">
<svg aria-hidden="true" focusable="false">
<use xlink:href="#icon-search"/>
</svg>
</button>
</form>The button displays only an icon. The aria-label "Search" provides a relevant accessible name. Since there is no visible text label, test 11.9.2 does not apply. Test 11.9.1 is passed.
✅ Compliant : Explicit buttons in a multi-step form
<form>
<fieldset>
<legend>Step 2: Your contact information</legend>
<label for="name">Name</label>
<input type="text" id="name" name="name">
</fieldset>
<button type="button">Previous step</button>
<button type="submit">Validate my information</button>
</form>Each button describes its action precisely. "Validate my information" is more robust than "Validate" alone. The accessible names match the visible labels: tests 11.9.1 and 11.9.2 are passed.
Tips and pitfalls
⚠️ "Validate" alone is not always sufficient
"Validate", "Submit" or "Continue" seem descriptive but become ambiguous as soon as a page contains multiple forms. This is the most common error on user account pages in audits. Prefer "Validate the order", "Send the message", "Continue to delivery".
⚠️ An aria-label that overrides without including the visible text
When you add an aria-label to a <button> that already contains visible text, the accessible name becomes exclusively that aria-label. If it does not contain the visible text, test 11.9.2 fails and voice command users can no longer activate the button by its displayed label. Practical rule: the aria-label should repeat the visible text, ideally at the beginning of the value, then supplement if needed.
⚠️ Icon-only button: test 11.9.2 does not apply
A button that displays only an SVG icon without visible text has no visible text label. Test 11.9.2 (label in name) therefore does not apply. Only test 11.9.1 comes into play: the accessible name must be relevant, provided via aria-label or aria-labelledby. Do not rely solely on title for relevance, as it is rarely reported by mobile screen readers.
⚠️ Special cases of criterion 11.2 (test 11.9.2)
Test 11.9.2 follows the same special cases as criterion 11.2. In practice, certain aria-labelledby configurations pointing to multiple text sources can create situations where exact correspondence with the visible label is impossible to achieve simply. In these edge cases, document the choice in the audit report and verify that the user experience remains consistent for voice command tools.
💡 Voice command, a revealer of naming inconsistencies
Ask yourself this question before closing DevTools: if someone speaks aloud the text displayed on the button, can voice command software activate it? If the answer is no because the aria-label says something else, you have a failure of test 11.9.2. This reflex detects in seconds inconsistencies invisible to the naked eye.
Frequently asked questions
Which HTML elements are covered by RGAA criterion 11.9 on button labels?
All buttons present in a form: <input type="submit">, <input type="reset">, <input type="image">, <input type="button">, <button> regardless of its type, and any element bearing role="button". Buttons outside forms (pure JavaScript actions) fall under criterion 7.1.
What is the difference between tests 11.9.1 and 11.9.2 for verifying an RGAA button label?
Test 11.9.1 verifies that the label and accessible name are understandable and not generic. Test 11.9.2 verifies that the accessible name contains the visible text, in accordance with WCAG 2.5.3 criterion "Label in Name". A button can pass 11.9.1 and fail 11.9.2: for example, an aria-label="Launch the search" is relevant but does not contain the visible text "Search".
How to verify the accessible name of a button during an RGAA audit?
In Chrome or Firefox DevTools, select the button element, open the Accessibility tab and read the "Name" field. You get the accessible name calculated by the browser without manually climbing the cascade aria-labelledby → aria-label → text content → value → title. For test 11.9.2, then compare this name with the visible text displayed on screen.
How to assess RGAA compliance of a "Continue" button in a multi-step form?
It is debatable. Unlike links, the RGAA does not define an accepted context for buttons in its glossary, which tends to require an explicit label independent of context. A pragmatic approach, detailed in the Temesis article by Éric Gateau, accepts "Continue" when the multi-step form provides an immediate, unambiguous context (section title, explicit <legend>). In strict audit, prefer "Continue to the next step".
How to determine if <button type="reset">Reset</button> complies with RGAA criterion 11.9?
On the label front, yes: "Reset" clearly describes the function. But type="reset" buttons are a recognized UX bad practice for years, as an accidental click erases all entries without confirmation. Accessibility and ergonomics agree on this point: avoid them, or add a confirmation before execution.