Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Ensure tables have unique accessible names

Checks that data tables have unique accessible names

Utilities
Quick take
Typical fix time 10 min
  • Each data table must have a unique `<caption>` or `aria-label`
  • Helps screen reader users distinguish between multiple tables
  • Avoid repetitive or generic names like 'Table 1'
Why it matters: When multiple tables are present, unique names allow users of assistive technology to quickly identify and navigate to the data they need.

Rule Details

Accessible names for tables provide context for users of assistive technologies, especially when a page contains multiple tables.

Code Example

<!-- ✅ GOOD: Using <caption> -->
<table>
  <caption>Monthly Sales Data (2023)</caption>
  <thead>...</thead>
  <tbody>...</tbody>
</table>
 
<!-- ✅ GOOD: Using aria-label -->
<table aria-label="Employee Directory">
  <thead>...</thead>
  <tbody>...</tbody>
</table>

Why It Matters

  • Navigation: Screen reader users can pull up a list of tables; unique names help them choose the right one.
  • Context: Explains what the data represents before the user starts diving into rows and columns.
  • Clarity: Prevents confusion when similar-looking tables are used for different purposes.
  • Compliance: Supports WCAG requirements for providing names for structural elements.

Exceptions

  • Simple data tables can sometimes fail more from missing header relationships than from missing enhancements such as captions or mobile wrappers, so prioritize the strongest semantic issue.
  • Do not convert layout structures into data-table markup just to satisfy a rule; the correct fix may be to remove table semantics entirely.
  • When several table-accessibility issues overlap, resolve the header-cell relationship first because downstream announcements depend on it.

Standards

  • Align the implementation with W3C WAI: WCAG Overview and verify the rendered experience, not only the source code.
  • Align the implementation with MDN: Accessibility and verify the rendered experience, not only the source code.

Verification

Automated Checks

  • Inspect the browser accessibility tree or accessibility pane for the relevant element, role, or accessible name.
  • Run an automated accessibility checker such as axe or Lighthouse where applicable.

Manual Checks

  • Test the affected UI with keyboard-only navigation and confirm the rule holds in the rendered experience.
  • Re-test one representative user flow with a screen reader if this rule affects a key interaction.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Verify that every table has a unique accessible name via caption or ARIA attributes.

Fix

Auto-fix issues

Add a unique `<caption>` or `aria-label` to the table.

Explain

Learn more

Explain why unique table names are necessary for users who rely on screen readers to navigate complex data.

Review

Code review

Review the rendered markup and interactive states that affect Ensure tables have unique accessible names. Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule, and note how to verify the fix with browser accessibility tooling or assistive tech.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

axe DevTools
deque.comTool

Rules that often go hand-in-hand with this one.

Use semantic table markup for screen readers

Data tables use proper semantic markup with headers, captions, and scope attributes for screen reader accessibility.

Accessibility
Ensure table headers associate with data cells

Checks that table headers have associated data cells

Accessibility
Use unique IDs for active elements

All focusable or active elements must have a unique ID attribute.

Accessibility
Place list items within list containers

List item elements (li) must always be direct children of a list container (ul, ol, or menu) to maintain valid HTML structure and correct screen reader announcements.

Accessibility

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385