Skip to main content
Accessibility AccessLint 0.16

<summary> elements must have an accessible name.

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-label attribute on the element.
  • An aria-labelledby attribute 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