Tables

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use for data that needs comparison across rows and columns.

What to draw

Show the title, headers, cells, and sorting when present. Plan how data can be read on small screens.

How it behaves

Static cells need no focus. Internal controls follow their own patterns; scrolling must work by keyboard when needed.

What to document in Figma

Document which headers describe each value, reading order, and sorting controls.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing components of type Tables.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

Before reading the data, can you perceive the relationship between rows and columns?
Does the table have a title or caption explaining its purpose?
Are row and column headers visually clear?

Designing for mouse use (any pointing device)

When the table offers sorting or actions, does the control provide visual feedback?
Are clickable areas inside cells distinguishable from static data?
Does a horizontally scrolling table indicate that more content is available?

Designing for gesture use

On small screens, does the table remain readable and understandable?
Is horizontal scrolling easy to perform, if present?
Does responsive reorganization preserve headers and data relationships?

Designing for keyboard use (any non-pointing device)

Can a horizontally scrolling table receive focus to allow keyboard scrolling?
Do sorting and action controls have visible focus?
Does focus order follow the visual and logical order of the data?

Designing for screen reader use

Is the table caption or title announced?
Are column and row headers associated with the data?
Are sorting changes announced when applicable?

Interaction methods

Possible interaction methods for components of type Tables.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

Static tables require no interaction.
Clicking a sortable header changes the sort order when that feature exists.
Links and buttons inside cells follow their own patterns.

Keyboard interaction (any non-pointing device)

Static tables should not add focus to cells unnecessarily.
Internal controls should be reachable with TAB.
A scrollable container can receive tabindex="0" to allow keyboard scrolling.

Keyboard (or gesture) interaction + screen reader

Use caption for the table title or description.
Use th with scope for simple headers.
Complex tables should associate headers and cells programmatically.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing tables

Keyboard navigation

WHEN I use the keyboard to navigate a table with interactive controls
I SEE visible focus on available controls
THEN, when the table has horizontal scrolling
I SEE that I can access and scroll the container when needed

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and navigate the component
- I HEAR the table's title or caption.
- I HEAR that the content is a table.
- I HEAR the headers associated with data cells.
THEN, when I interact with the component, when applicable
I HEAR or perceive that the corresponding information, state, content, or action is available.

Mobile screen reader

WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to navigate the component, the following happens:
- I HEAR the table's title or caption.
- I HEAR that the content is a table.
- I can understand the relationship between headers and data.
THEN, when I interact with the component, when applicable
I HEAR or perceive that the corresponding information, state, content, or action is available.

Considerations

Considerations for components of type Tables.

Do not use tables for visual layout.
Complex tables require more careful association between headers and cells.
Responsive versions should not remove important semantic relationships.

References

Additional references for components of type Tables.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.