About this AccessLint rule
The <summary> element acts as the toggle control for a <details> disclosure widget. When a user clicks or activates it, the content inside the parent <details> element expands or collapses. Because it functions as an interactive control, it must have an accessible name so that assistive technology can communicate its purpose.
Screen reader users rely on the accessible name to understand what content will appear when they activate the control. A <summary> element with no text content and no labeling attribute is announced as something like "button" or "disclosure triangle" with no further context. The user has no way to decide whether to expand the widget without guessing what it contains.
This rule maps to WCAG 2 success criterion 4.1.2 (Name, Role, Value) at Level A. That criterion requires all user interface components to have a name that can be programmatically determined. Since <summary> is an interactive element with an implicit role (some browsers expose it as a button), it must meet this requirement.
How the accessible name is determined
The accessible name of a <summary> element can come from several sources:
- Text content placed directly inside the element.
- An
aria-labelattribute on the element. - An
aria-labelledbyattribute referencing another element that contains text.
The name must not be empty. It also must not consist solely of the browser's default disclosure triangle marker (the ::marker pseudo-element). If the <summary> has no text and no ARIA labeling attribute, the accessible name is empty, and this rule fails.
How to fix it
Add descriptive text to the <summary> element. The text should clearly indicate what content the <details> section contains when expanded.
If visible text is not appropriate for the design, use aria-label or aria-labelledby to provide a name. However, visible text is the preferred approach because it benefits all users, not just those using assistive technology.
Things to be aware of
Browsers differ in how they handle the disclosure triangle indicator. Some include the triangle character in the computed accessible name, while others do not. Do not rely on the triangle alone as the name.
The <summary> element does not need to be the first child of <details> to function as its toggle control, though the HTML specification recommends that placement. This rule applies regardless of the element's position within <details>.
If a <summary> element has an explicit ARIA role (for example, role="button"), this rule does not apply to it directly. Other rules, such as the one requiring buttons to have an accessible name, cover that case instead.
Examples
Failing: summary with no text content
This <summary> element has no text and no ARIA labeling attribute. Screen readers cannot announce a meaningful name for the control.
<details>
<summary></summary>
<p>This is a website. We are available 24/7.</p>
</details>
Passing: summary with text content
Adding descriptive text inside the <summary> element gives it an accessible name.
<details>
<summary>Opening times</summary>
<p>This is a website. We are available 24/7.</p>
</details>
Passing: summary with aria-label
When visible text is not feasible, aria-label can provide the accessible name.
<details>
<summary aria-label="Opening times"></summary>
<p>This is a website. We are available 24/7.</p>
</details>
Passing: summary with aria-labelledby
The aria-labelledby attribute can reference text in another element to supply the name.
<span id="opening-times">Opening times</span>
<details>
<summary aria-labelledby="opening-times"></summary>
<p>This is a website. We are available 24/7.</p>
</details>
Passing: summary that is not the first child of details
The <summary> element still works as the disclosure control even when it is not the first child of <details>. The accessible name comes from its text content as usual.
<details>
<p>This is a website. We are available 24/7.</p>
<summary>Opening times</summary>
</details>
Detect accessibility issues automatically
Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.
Help us improve our guides
Was this guide helpful?
๐
Trusted by teams worldwide
Validate at scale.
Ship accessible websites, faster.
Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.
Scheduled Reports
API Access
Open Source Standards
$7
/ 7 days
Pro Trial
Full Pro access. Cancel anytime.
Start Pro Trial โ
Join teams across 40+ countries