HTML Guides for summary

The summary element needs an explicit role attribute when the W3C validator detects it’s being used in a context where its implicit ARIA semantics are unclear or overridden.

The summary element is designed to be used as the first child of a <details> element, where it acts as a clickable disclosure toggle. When used correctly inside <details>, it has an implicit ARIA role and doesn’t need additional attributes.

This validation warning typically appears when:

• The summary element is used outside of a <details> element.
• The summary element has an explicit role attribute that requires additional ARIA properties (e.g., role="checkbox" requires aria-checked, or role="heading" requires aria-level).

The simplest fix is to ensure summary is used correctly as a direct child of <details>, and to remove any unnecessary or conflicting role attributes.

Example with the issue

<!-- summary outside of details triggers the warning -->

<summary>Click to expand</summary>
<p>Some content here.</p>

<!-- Or summary with an incomplete role override -->

<details>
  <summary role="heading">Section Title</summary>
  <p>Some content here.</p>
</details>

How to fix it

<!-- Use summary correctly inside details -->

<details>
  <summary>Click to expand</summary>
  <p>Some content here.</p>
</details>

<!-- If you need a heading role, include the required aria-level -->

<details>
  <summary role="heading" aria-level="3">Section Title</summary>
  <p>Some content here.</p>
</details>

If you don’t have a specific reason to override the role, simply remove the role attribute and let the summary element keep its native semantics within <details>.

The aria-expanded attribute is redundant on a summary element when it is the direct child of a details element, because the browser already communicates the expanded/collapsed state through the native open attribute on details.

The summary element, when used as the first child of a details element, acts as the built-in toggle control. Assistive technologies already understand this relationship and automatically convey whether the disclosure widget is open or closed based on the details element’s open attribute. Adding aria-expanded to summary in this context creates duplicate semantics, which can confuse screen readers by announcing the state twice.

If you’re using JavaScript to toggle aria-expanded manually, you can safely remove it and rely on the native behavior instead. The details/summary pattern is one of the best examples of built-in accessibility that requires no extra ARIA attributes.

Incorrect Example

<details>
  <summary aria-expanded="false">More information</summary>
  <p>Here are the additional details.</p>
</details>

Correct Example

<details>
  <summary>More information</summary>
  <p>Here are the additional details.</p>
</details>

If you need the section to be open by default, use the open attribute on the details element:

<details open>
  <summary>More information</summary>
  <p>Here are the additional details.</p>
</details>

The <summary> element serves as the clickable disclosure toggle for a <details> element. Because its built-in behavior is inherently interactive — clicking it expands or collapses the parent <details> content — the HTML specification assigns it an implicit button role. This means assistive technologies like screen readers already announce <summary> as a button without any additional markup.

When you explicitly add role="button" to a <summary> element, the W3C validator flags it as unnecessary. While this doesn’t cause functional problems, redundant ARIA roles are discouraged by the first rule of ARIA use: if an HTML element already has the semantics you need, don’t re-add them with ARIA attributes. Redundant roles add noise to your code, can confuse other developers into thinking custom behavior is being applied, and in edge cases may interact unexpectedly with certain assistive technologies.

This principle applies broadly — many HTML elements have implicit roles (e.g., <nav> has navigation, <main> has main, <button> has button). Adding the role they already carry is always unnecessary.

How to fix it

Remove the role="button" attribute from the <summary> element. No replacement is needed since the semantics are already built in.

Examples

❌ Incorrect: redundant role="button" on <summary>

<details>
  <summary role="button">Show more information</summary>
  <p>Here is the additional information that was hidden.</p>
</details>

The validator will report: The “button” role is unnecessary for element “summary”.

✅ Correct: <summary> without an explicit role

<details>
  <summary>Show more information</summary>
  <p>Here is the additional information that was hidden.</p>
</details>

The <summary> element’s implicit button role ensures assistive technologies already treat it as an interactive control. No additional attributes are required.

✅ Correct: a more complete <details> example

<details>
  <summary>I have keys but no doors. I have space but no room. You can enter but can't leave. What am I?</summary>
  <p>A keyboard.</p>
</details>

Clicking the <summary> toggles the parent <details> element between its open and closed states. Screen readers announce it as a button automatically, and keyboard users can activate it with <kbd>Enter</kbd> or <kbd>Space</kbd> — all without any explicit ARIA role.

The summary attribute was used in HTML 4 to provide a text description of a table’s structure and purpose, primarily for screen reader users. In HTML5, this attribute was deprecated because it was invisible to sighted users, creating an unequal experience. It was also frequently misused — authors often duplicated the table’s caption or provided unhelpful descriptions, diminishing its accessibility value.

The HTML Living Standard offers several better alternatives, each suited to different situations:

1. Use a <caption> element — Best for a concise title or description that benefits all users, not just screen reader users. The <caption> must be the first child of the <table> element.
2. Use a <figure> with <figcaption> — Ideal when you want to provide a longer description or contextual information alongside the table. This approach also semantically groups the table with its description.
3. Simplify the table — If your table is straightforward with clear headers, it may not need any additional description at all. Well-structured <th> elements with appropriate scope attributes often provide enough context.

From an accessibility standpoint, the <caption> and <figcaption> approaches are superior because they are visible to all users and part of the document flow. Screen readers announce <caption> content when a user navigates to a table, providing the same benefit the summary attribute once offered — but now everyone can see it.

Examples

❌ Obsolete: Using the summary attribute

This triggers the validation warning because summary is no longer a valid attribute on <table>.

<table summary="This table shows monthly sales figures for 2024.">
  <tr>
    <th>Month</th>
    <th>Sales</th>
  </tr>
  <tr>
    <td>January</td>
    <td>$1,000</td>
  </tr>
  <tr>
    <td>February</td>
    <td>$1,200</td>
  </tr>
</table>

✅ Fix 1: Using a <caption> element

Replace the summary attribute with a <caption> as the first child of the <table>. This is the most common and straightforward fix.

<table>
  <caption>Monthly sales figures for 2024</caption>
  <tr>
    <th>Month</th>
    <th>Sales</th>
  </tr>
  <tr>
    <td>January</td>
    <td>$1,000</td>
  </tr>
  <tr>
    <td>February</td>
    <td>$1,200</td>
  </tr>
</table>

✅ Fix 2: Using <figure> and <figcaption>

This approach is useful when you want to provide a longer description or when the table is referenced as a figure within surrounding content.

<figure>
  <figcaption>
    Monthly sales figures for 2024, showing a steady increase in revenue
    during the first quarter.
  </figcaption>
  <table>
    <tr>
      <th>Month</th>
      <th>Sales</th>
    </tr>
    <tr>
      <td>January</td>
      <td>$1,000</td>
    </tr>
    <tr>
      <td>February</td>
      <td>$1,200</td>
    </tr>
  </table>
</figure>

✅ Fix 3: Simplify and rely on clear headers

For simple tables where the data is self-explanatory, well-labeled headers with scope attributes may be sufficient. No extra description is needed.

<table>
  <thead>
    <tr>
      <th scope="col">Month</th>
      <th scope="col">Sales</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>January</td>
      <td>$1,000</td>
    </tr>
    <tr>
      <td>February</td>
      <td>$1,200</td>
    </tr>
  </tbody>
</table>

You can also combine approaches — use a <caption> for a brief title and wrap the table in a <figure> with a <figcaption> for additional context. The key takeaway is to remove the summary attribute and use visible, semantic HTML elements to describe your table instead.