Wide markdown tables render as stacked key-value lists — accessibility concern for neuroatypical users

Problem

When Claude outputs a markdown table wider than the terminal, Claude Code's renderer converts it to a stacked key-value format — one field per line with separator bars between records:

#: 1
Item: Biological memory for Claude
Category: Memory & Context
Importance: High
Urgency: High
Action: Evaluate + implement
────────────────────────────────────────
#: 2
Item: Precompact comparison
Category: Memory & Context
Importance: High
Urgency: High
Action: Compare + improve ours
────────────────────────────────────────

A 27-row, 7-column table becomes ~190 vertical lines in this format. The same data as a box-drawing table would be ~30 lines.

Why this is an accessibility issue

For users with dyslexia and/or ADHD, the stacked format is actively harmful:

• Massive vertical scrolling — The eye must track down hundreds of lines to compare items. Each record occupies 7+ lines instead of 1. The cognitive load of scrolling and re-orienting is exhausting.
• No scanability — Tables exist precisely so humans can scan a column vertically (e.g., compare all "Importance" values at a glance). The stacked format destroys this. Every value is at a different horizontal position on a different line.
• Repetitive labels — Every record repeats all column names. For ADHD users, the visual noise of repeated headers makes it nearly impossible to focus on the actual data.
• Lost spatial relationships — Neuroatypical users often rely on spatial position to track data. In a table, "row 5, column 3" is a stable location. In the stacked format, that same value could be on line 37 or line 42 depending on content length.

This is not a preference — it's a functional barrier that makes structured data unreadable for a meaningful percentage of users.

What renders correctly

Narrow tables (2-3 short columns) render as box-drawing and work beautifully:

┌─────────────────────────────────────┬───────┬────────────────────────────┐
│                Tier                 │ Count │           Action           │
├─────────────────────────────────────┼───────┼────────────────────────────┤
│ High Importance + High Urgency      │ 3     │ Do first                   │
├─────────────────────────────────────┼───────┼────────────────────────────┤
│ Medium                              │ 10    │ Evaluate when relevant     │
└─────────────────────────────────────┴───────┴────────────────────────────┘

This is compact, scannable, and accessible. The problem is only with tables that exceed the terminal width.

Suggested solutions

In priority order:

1. Horizontal scroll for wide tables — Render the box-drawing table at full width and allow horizontal scrolling (like code blocks do in many terminals). This preserves the table structure entirely.

1. Truncate cells with ellipsis — If a table is too wide, truncate long cell content with … to fit the terminal width while preserving the tabular layout. The user can resize the terminal to see more.

1. Column-priority rendering — Render the first N columns that fit as a proper table, and add a note like (+3 columns — widen terminal to see).

1. User-configurable threshold — Add a setting like tableRenderMode: "box" | "stacked" | "scroll" so users can choose their preferred rendering.

Any of these would be a significant accessibility improvement over the current stacked format.

Environment

• Claude Code v2.1.38
• macOS (iTerm2, 120-column terminal)
• The behavior is consistent across terminal widths

Context

I've been working around this by instructing Claude to keep tables under 4 columns and split wide data into multiple grouped tables. This works but puts the burden on the user to manage output formatting, which shouldn't be necessary.

Thank you for considering this. The box-drawing table renderer is excellent — it just needs a better fallback for wide tables.