How can I make a custom data grid keyboard accessible?
Quick answer
First decide whether people mainly read the data or interact with it. For reading, use a semantic HTML table with a caption and appropriate headers; a custom ARIA grid has a different structure and should be reserved for an interactive experience. If you build a grid, specify which keys move between cells, how users enter and leave controls inside a cell, and what happens at the edges. Treat that specification as a design contract and check it with a keyboard.
The question, the details, the next step.
I have rows and columns of data with buttons and editable fields. Should I build a custom grid, or use a regular table?
Start with what people need to do. If they primarily read or compare data, prefer a semantic HTML table. Microsoft’s accessibility guidance recommends an accessible name and header information for data tables, with elements such as caption, thead, and th as examples [S2].
A grid makes more sense when people need to navigate among cells and act within them. It is not just a table with different styling. Microsoft describes a grid structure containing rows and cells or headers, and calls for an accessible name for the grid and its parts [S1]. That guidance does not establish which keyboard behavior a web grid should use.
For your example, decide whether users need cell-by-cell navigation or simply need to Tab through the buttons and fields. If the latter is enough, a table with controls in a logical order may be simpler.
If I do choose a grid, what should I decide about arrow keys and Tab before coding?
Write down the keyboard behavior first. One possible design is: one cell is the current navigation stop; arrow keys move to adjacent cells; Tab enters a control in the current cell; Escape returns from that control to the cell. These are proposed choices, not universal requirements established by the sources here. A different design may suit users who need to Tab through every control.
Specify edge behavior too. Does Right Arrow stay at the last column or move to the next row? Does Down Arrow move to the same column in the next row? What happens in an empty cell? Avoid leaving these decisions to accidental behavior.
Microsoft’s WinUI guidance distinguishes Tab movement among actionable controls from arrow-key movement within some control groups, and recommends a logical, predictable tab order [S3]. It is WinUI guidance, not a complete web-grid specification, so treat it as a design consideration rather than a web requirement.
How should I handle a cell that contains a button or an editable field?
Decide how keyboard users move between the cell and its control. A possible contract: arrow keys move between cells while navigating; Enter or F2 enters the control; the control uses its own keys; Escape returns focus to the cell; and Tab follows a defined exit rule. These are example choices to evaluate, not source-backed web requirements.
For example, imagine project rows with an “Owner” field and an “Archive” button. When focus is on Owner, document whether Enter starts editing and how Escape exits. When focus is on Archive, specify whether Tab goes to another control or leaves the grid. Avoid using the same key to edit and move away without a predictable way to recover.
If each cell has several controls and users need to reach all of them with Tab, consider whether a semantic table is a better fit. The cited references do not settle that choice or define a complete web keyboard model.
What should I put in a short specification, and how can I check it?
Record the structure, focus model, key behavior, and edge cases in plain language. Then check the scenarios without a mouse: enter the component, move across and down, reach and leave each kind of control, and exit. Check that focus is visible and that the row, column, and control information makes sense to a user. These are practical review prompts, not procedures prescribed by the cited guidance.
A starter contract, with choices to confirm:
“Structure: [semantic table / interactive grid]. Entry: [first cell / remembered cell]. In grid navigation: [arrow-key behavior]. Enter a cell control: [key]. Return: [key]. At row and column edges: [behavior]. Tab: [moves between controls / exits the grid]. Empty cells: [behavior].”
Check the chosen behavior with your actual content, including the first and last cells and a cell with multiple controls. The references cannot confirm that an implementation works; verify it in the finished interface.
A practical checklist
Choose a semantic table for primarily reading, or document why cell-by-cell interaction is needed.
Define the grid’s entry point and whether one cell or each control participates in Tab navigation.
Specify arrow-key movement, including behavior at row and column edges.
Document how users enter, operate, and leave controls inside cells.
Check empty cells, multiple controls, and first and last cells using only a keyboard.
A few more useful answers
Does adding an ARIA grid role automatically make keyboard navigation work?
No. The cited grid guidance describes structure and naming, but does not specify cell-to-cell navigation or access to embedded controls [S1]. Define and implement those behaviors separately.
Can I use arrow keys to move between cells and Tab to reach buttons?
That can be a deliberate design, but document how users switch between cell navigation and controls, and what Tab does at the grid boundary. The sources here do not establish it as a required web pattern.
What if every button and field needs to be reachable with Tab?
Consider whether a semantic table with controls in a logical tab order better fits the task. Microsoft’s table guidance supports providing a name and header information; it does not prescribe keyboard behavior for embedded controls [S2].
Sources
References used for this guide.
- [S1] ARIA Grid Structure Error — Microsoft Learn learn.microsoft.com · Checked
- [S2] ARIA Data Table Error — Microsoft Learn learn.microsoft.com · Checked
- [S3] Keyboard interactions — Windows apps | Microsoft Learn learn.microsoft.com · Checked