HTML Guides for summary

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.