Mobile data table design starts with the task: comparing values across records needs a different layout from looking up one record and taking an action. Keep a real table when row-and-column relationships matter. Consider cards or expandable details when each record can stand alone. Choose the pattern before shrinking the text or hiding columns.
A small screen does not make the information less important. The design still needs clear labels, understandable units, and a reliable way to reach every necessary value. The goal is to preserve the user’s decision, even when the arrangement changes.
Mobile data table design: identify the reading task
Imagine a fictional order list with order ID, customer, total, payment status, delivery date, and an action link. A support agent might open one order to answer a customer. A finance colleague might compare totals and payment states across several orders. Those tasks use the same data differently.
For lookup, an order card can keep the identifier and next action together. For comparison, repeated cards can force people to remember a value while scrolling to the next record. Aligned columns reduce that memory burden. Treat this as a design hypothesis to test with your users, rather than a universal preference for one visual style.
Write a concrete task before choosing a layout: “Find the highest unpaid order among these five records” or “Open order A-103 and check its delivery date.” A vague goal such as “make the table mobile-friendly” does not tell you which information must remain visible.
Keep a table when comparison is central
A horizontally scrollable table can preserve relationships that would be lost in cards. Put it inside a container that scrolls independently, so the entire page does not become wider than the screen. Keep an identifying column close to the values people compare, and consider whether a sticky identifier genuinely helps at the narrowest supported width.
A scroll affordance should make the hidden content discoverable. You might show a partial next column, a subtle edge treatment, and a short instruction above the table. Do not rely on a tiny scrollbar being visible on every device. Test whether people notice the additional columns without prompting.
Keep headers meaningful when the table moves. A currency value needs a currency label; a date needs a recognizable format. If you abbreviate a heading, provide an explanation people can reach on touch and keyboard as well as with a pointer. A hover-only tooltip is insufficient for a mobile task.
The WCAG reflow guidance allows an exception for content whose meaning or use requires a two-dimensional layout, including data tables. It distinguishes the table from the content within individual cells. This is a reason to handle the table carefully, not permission to make the rest of the page overflow.
Use cards for independent records
A card works well when someone needs to understand one order, see its state, and open its details. For the fictional order list, give each card a visible order ID, the total with currency, payment status, and an explicit “View order” link. Secondary details can follow in a consistent order.
Repeat labels where needed. A number without a label becomes ambiguous once it leaves its original column. Keep “Total” and “Delivery date” as visible content rather than expecting users to remember the desktop header. Do not distinguish paid and unpaid orders by color alone.
The tradeoff is vertical length. Six fields repeated across twenty cards can make scanning slow. Filtering or a clear search control may help people reach the right subset. Avoid making every record visually elaborate when a compact list with a detail view would support the task better.
Simon Willison’s responsive-table demonstration provides several patterns to explore, including scrolling, cards, column controls, and expandable records. Use such demonstrations to compare behaviors. They do not establish that one pattern is accessible or effective in your particular implementation.
Set column priorities explicitly
If the table contains more information than the narrow layout can comfortably display, rank columns by task value. A useful starting point is identity, decision-critical values, and the next action. Put supporting details behind a clear route that remains available.
- Always available: the order ID and the values necessary for the current task.
- Easy to reveal: supporting fields that help explain the record.
- Context-dependent: fields useful only to another role or workflow.
For a payment-review view, total and payment status may outrank delivery date. For a dispatch view, delivery details may outrank the amount. Document the priority for each view instead of assuming the same hidden-column rule fits everyone.
When users can choose columns, make the selected state clear and give them a way to restore a useful default. A hidden field should not silently disappear from an export or change the meaning of a filter. Explain whether column visibility affects only presentation.
Preserve semantics as the presentation changes
Use table markup for genuinely tabular information. The W3C tables tutorial explains captions, header cells, and associations between headers and data. Those relationships let assistive technology convey context that sighted readers may infer from alignment.
The MDN table reference shows examples of captions and scoped row and column headers. Start with a straightforward structure. If your design needs complex spanning headers, check that each data cell still has the intended context.
Changing CSS display behavior or building a separate mobile view deserves a fresh accessibility check. Do not assume that visually stacked cells keep the same navigation behavior in every browser and screen reader. If you render cards instead, give them a clear reading order and meaningful labels, and avoid exposing duplicate desktop and mobile copies to assistive technology.
Choose semantic HTML before adding ARIA. The implementation should describe the real interaction, including whether an expandable control is open and what it reveals. A decorative arrow alone does not communicate that state.
Test scrolling, focus, and recovery together
Walk through the actual tasks with a keyboard. Confirm that people can reach and operate interactive controls, access any scrollable region that needs keyboard interaction, and see where focus is. Check that sticky headers, sticky columns, and page overlays do not cover the focused control or its label.
Next, test a narrow viewport and enlarged text with realistic content. Use long customer names, large totals, missing dates, and translated labels. A layout that fits only short sample values is not ready for production. Let useful text wrap rather than compressing it into unreadably small type.
Check a screen-reader journey for both a single record and a comparison task. Ask whether the user hears the correct header context, can identify the intended action, and understands expanded details. Desinance’s accessible form design checklist covers related labeling, focus, and error-handling concerns for filters and editing controls.
A practical handoff decision
Record the selected pattern, the task it supports, the always-visible fields, and how someone reaches the remaining information. Include the narrowest tested width, text enlargement, keyboard behavior, and any unresolved accessibility findings. Desinance’s design tokens vs components guide provides context for turning a repeatable table pattern into a maintained component.
For the fictional order list, choose scrolling when the main job is cross-record comparison, and a compact card or detail layout when the main job is opening one order. Keep a clear path to the full information in either case. The strongest mobile table is the one that lets users complete their real task without losing the labels or relationships that make the data understandable.
