Turn Data Table Findings into Accessibility Tickets

Table bugs become fixable when the ticket names the table, the missing relationship, and the cell navigation path that loses row or column context.

Use this guide for audit notes about missing table headers, visual-only table structure, sortable columns without state, responsive card layouts that lose labels, or complex tables where screen readers cannot connect data cells to the right headers.

Open this data table finding in the generator

What to capture from the finding

Table purpose: order history, invoice list, comparison table, pricing matrix, results table, or admin data grid.
Lost relationship: missing column headers, row headers, grouped headers, caption, sort state, or label context after responsive reflow.
Representative cell: quote one cell value and the row or column context that should be announced with it.
Assistive technology path: screen reader table navigation, keyboard focus, mobile screen reader swipe order, or browser accessibility tree inspection.
Implementation clue: native table markup, custom grid role, CSS display changes, CMS component, or JavaScript data grid.

Ticket structure

Title:
[Severity] Page or component: data table does not expose row or column context

User impact:
Explain what users cannot understand when cells are announced without the relevant headers, caption, row label, or sort state.

Evidence:
- Table or component:
- Representative cell:
- Expected row or column context:
- Actual announcement or accessibility tree result:
- Assistive technology and browser:
- Selector or component:

Likely WCAG references to verify:
- 1.3.1 Info and Relationships, when visible table structure is not programmatically exposed.
- 2.4.6 Headings and Labels, when the table has no clear name or caption.
- 4.1.2 Name, Role, Value, when sortable headers, custom grids, or interactive cells lack role, state, or value.

Acceptance criteria:
- Data cells are programmatically associated with the correct column and row headers.
- The table has a clear accessible name or caption when the surrounding heading is not enough.
- Sortable columns expose their button/control role, accessible name, and current sort state.
- Responsive table/card views keep each value's label available to screen reader users.
- The agreed screen reader path announces representative cells with the expected context.

Paste your data table note into the generator when you want this structure drafted from raw audit text.

Example conversion: missing column headers

Raw note:
Order history table visually shows Date, Total, and Status headings, but the cells are built with divs. NVDA reads "59.90 euros" without saying Total.

Developer ticket:
[High] Account order history: table cells are not associated with column headers

User impact:
Screen reader users cannot reliably tell whether a value is an order date, total amount, status, or action when browsing the order history. This makes order review slower and increases the risk of opening the wrong order.

Evidence:
- Page: Account > Order history
- Representative cell: "59.90 euros"
- Expected context: Total column for the selected order row
- Actual result: NVDA announces the cell value without column context
- Implementation clue: visual table is built from styled div elements

Likely WCAG references to verify:
- 1.3.1 Info and Relationships
- 2.4.6 Headings and Labels

Acceptance criteria:
- The order history uses native table markup or equivalent programmatic row and column relationships.
- Each data cell is associated with the correct visible header.
- The table has a useful accessible name such as "Order history".
- NVDA table navigation announces representative cells with their column context.

Example conversion: sortable column state

Raw note:
Search results table has sortable Price and Date columns. The visual arrow changes, but VoiceOver only announces "Price button" and does not expose ascending or descending state.

Developer ticket:
[Medium] Search results table: sortable column buttons do not expose current sort state

User impact:
Screen reader users can activate the sort controls but cannot confirm which column is sorted or whether the current order is ascending or descending.

Evidence:
- Component: search results table
- Controls: Price and Date column headers
- Screen reader path: VoiceOver, move to column header button
- Actual result: "Price button"
- Expected result: Price button with current sort direction or equivalent state

Likely WCAG references to verify:
- 4.1.2 Name, Role, Value
- 1.3.1 Info and Relationships

Acceptance criteria:
- Sortable headers are keyboard operable controls.
- The current sorted column and direction are exposed programmatically.
- The visual arrow and programmatic state stay synchronized after each activation.
- VoiceOver announces the updated state after sorting.

Common fix directions

Prefer native tables for data: use table, caption, thead, tbody, th, td, and scope before reaching for ARIA.
Use row headers deliberately: mark row names, product names, invoice IDs, or comparison criteria as row headers when they identify the rest of the row.
Handle complex headers carefully: use headers and id relationships when grouped or multi-level headers cannot be expressed with simple scope.
Do not let responsive layout erase labels: stacked mobile rows still need each value's label available programmatically.
Retest real navigation: browser inspection is useful, but table keyboard commands in NVDA, JAWS, VoiceOver, or TalkBack catch context loss that visual review misses.

Paste-ready input for the generator

Data table finding:
Table or component:
Visible headers:
Representative cell value:
Expected row or column context:
Actual screen reader announcement:
Assistive technology and browser:
Selector or component:
Responsive/mobile behavior:
Sort or interaction state:
Retest notes:

Open the accessibility ticket generator and paste this structure with the audit note.