mcpField
T
table-accessibility

table-accessibility

github.com/owl-listenerDesign & UI10877 installsUpdated 20w ago
Repository

About table-accessibility

A design skill for accessible data tables, aimed at people building interfaces that present relationships across rows and columns. It covers semantic headers and labels, simpler structures, responsive behavior, and readability guidance.

Key features

  1. 01Use tables for two-dimensional data
  2. 02Add scoped row and column headers
  3. 03Give tables captions or labels
  4. 04Prefer simple table structures
  5. 05Plan responsive small-screen views
  6. 06Readability guidance and checklist

Use cases

  1. 01Designing accessible comparison tables
  2. 02Making schedules usable with screen readers
  3. 03Reviewing table layouts for mobile screens

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/owl-listener/inclusive-design-skills --skill table-accessibility

After installing, type/table-accessibilityin Claude Code to confirm it loaded.

Details

From the project README

Table Accessibility

Design tables that communicate structure and relationships — not just to sighted users scanning rows and columns, but to screen reader users who navigate one cell at a time.

When to Use a Table

Tables are for data that has relationships across two dimensions (rows and columns). Don't use tables for layout.

  • Use a table: comparing features across products, showing schedules, displaying data with consistent categories
  • Don't use a table: laying out a form, arranging cards, creating visual columns of unrelated content

Core Requirements

Every Table Needs Headers
  • Column headers: use with scope="col"
  • Row headers: use with scope="row"
  • Screen readers announce headers before each cell, so users always know which column and row they're in
  • Without headers, a screen reader user hears a stream of disconnected values with no context
Every Table Needs a Caption or Label
  • Use element for HTML tables
  • Or use aria-labelledby pointing to a visible heading
  • The caption describes what the table contains: "Pricing comparison for Standard, Pro, and Enterprise plans"
  • Not just "Table 1" or "Data"
Simple Tables Over Complex Tables
  • Prefer simple tables with one row of column headers
  • Avoid merged cells (colspan, rowspan) wherever possible
  • If merged cells are necessary, use proper headers/id/scope associations
  • If a table needs merged cells to make sense, consider whether it should be split into multiple simpler tables

Cognitive Accessibility for Tables

Visual Design
  • Zebra striping (alternating row colours) aids row tracking
  • Adequate cell padding (at least 8px) prevents crowding
  • Align numbers right, text left for readability
  • Highlight the header row with stronger contrast
Reduce Complexity
  • Maximum 5–7 columns for comfortable scanning
  • If more columns are needed, consider a different format or allow users to show/hide columns
  • Provide a summary or key takeaway above complex tables
  • Don't require horizontal scrolling — make tables responsive
Responsive Tables
  • On small screens: convert to card/list view where each row becomes a labelled card
  • Or allow horizontal scroll with a sticky first column
  • Never hide data on smaller screens without a way to access it
  • Test: can a mobile user access every piece of data?

Assessment Checklist

  • All tables have column and/or row headers with proper scope
  • All tables have a caption or accessible label
  • No merged cells (or properly associated headers if unavoidable)
  • Tables are responsive on small screens
  • Tables are not used for visual layout
  • Complex tables have a text summary of key findings
  • Cell padding and spacing support readability

Comments

Markdown supported