Tables with clear actions

User taskpurpose

Name the person, the task they need to finish, and the observable outcome. Keep one primary task.

Primary actionprimaryAction

Specify the action label, when it is available, what it changes, and how success is confirmed.

Loadingloading

Describe what stays visible during a request, how progress is communicated, and how repeated actions are prevented.

Empty stateempty

Distinguish a first visit, no results, and unavailable data where relevant. Give a useful next step.

Error and recoveryerror

State where errors appear, which input is preserved, and how someone retries or recovers without repeating completed work.

Keyboard and focuskeyboard

Define native controls, tab order, focus visibility, focus after updates, and any Escape or arrow-key behavior.

Labels and feedbackaccessibility

Name controls and errors clearly, describe screen-reader announcements, and keep meaning available without relying only on color.

Narrow and wide layoutsresponsive

Describe how content reflows at 320px, what remains visible, and the maximum reading width on wide screens. Do not shrink text to make it fit.

Completionsuccess

Specify the visible result, whether focus moves, and how the user continues or undoes the action when supported.

Columns and row actionscolumns

Specify column labels, formatting, alignment, priority, and a clear accessible name for each row action.

Search, sort, and paginationfiltering

Define the default sort, supported filters, no-results recovery, page changes, and which state survives navigation. Explicitly omit unused controls.

Selection and bulk actionsselection

Define whether selection exists; if it does, specify page versus all-results selection, selection count, confirmation, and partial failures.

• Apply a filter with no matches: explain the result and offer a clear way to reset that filter.
• Sort by a column using the keyboard: expose the active sort direction to assistive technology.
• At 320px, preserve row identity and essential actions; if horizontal scrolling is necessary, confine it to a labelled table region.
• If bulk actions exist, show exactly which records are selected and report partial failures without losing the result.

These are starting requirements, not a certification or a substitute for testing with people. Record a reason when a behavior does not apply.

Connect Amito to your AI assistant, fetch spec:table, and describe the behavior for each decision above. Ask the agent to run validate_design_spec to find missing decisions and placeholders.

{
  "pattern": "table",
  "decisions": {
    "purpose": "",
    "primaryAction": "",
    "loading": "",
    "empty": "",
    "error": "",
    "keyboard": "",
    "accessibility": "",
    "responsive": "",
    "success": "",
    "columns": "",
    "filtering": "",
    "selection": ""
  }
}