Accessibility · 5 min read

Density Is a Setting, Not a Style

Dense screens and accessible screens can be the same screen: give people control over spacing, and protect the essentials in every mode.

A team ships a compact redesign of an operations table because power users want more rows on screen. The same release leaves people who zoom in or use larger targets struggling to read and operate it. The problem isn’t that the table is dense. It’s that density is fixed for everyone.

I treat density as a user-controlled setting, not a fixed compromise: preserve the information, change the spacing, and protect the controls and warnings.

Two users, one table

Experts want information density. They use the same tool all day and often need to see more rows at once, without scrolling through information they rely on to make decisions. Cloudscape defines density as “the ratio of information visible compared to the space available.” That’s a useful way to frame the tradeoff: density is about how much information fits in a given space.

Other people need that same information to work differently on screen. Low-vision users may zoom in. People with motor disabilities may need larger targets they can reliably operate. Both groups need access to the table’s information, and both needs are legitimate.

Treating this as a choice between a dense interface and an accessible one misses the point. The information doesn’t need to disappear for the interface to adapt. The table can be compact for someone who wants more rows, while still supporting zoom, reflow and usable controls.

What the standard actually asks

WCAG is the Web Content Accessibility Guidelines, a standard for making web content more accessible. WCAG 2.2 success criterion 1.4.10 Reflow (Level AA) asks that content be presented without scrolling in two dimensions at 320 CSS pixels wide. CSS pixels are the units used to describe the size of content in a web layout. That width equals a 1,280-pixel-wide window zoomed to 400 percent.

Reflow means content adjusts to fit the available width instead of requiring someone to scroll both horizontally and vertically to use the page. The criterion exempts parts of content that need a two-dimensional layout for their usage or meaning. Its Understanding document lists data tables—not individual cells—among the exempted content.

That exemption has limits. It doesn’t extend to the table’s heading, search field or pagination. A passing example puts the table in its own scrolling container, so the table can scroll while everything around it still reflows.

WCAG 2.2 success criterion 2.5.8 Target Size (Minimum), Level AA, sets 24 by 24 CSS pixels as the minimum for pointer targets, with exceptions such as enough spacing. A pointer target is an interactive area someone can operate with a pointer, such as a mouse or touch input.

So the standard already allows a dense table. It doesn’t allow a dense page. Keep the exception where it belongs, and make the rest of the experience work at the available width.

Make density a setting

There are useful patterns for giving people control without making every table a one-off. IBM’s Carbon design system offers five data table row heights: 24 px (extra small, for highly dense layouts), 32 px (small), 40 px (medium, the default), 48 px (large) and 64 px (extra large, for rows with two lines of content). Carbon asks that the header, toolbar and pagination match the row size.

AWS’s Cloudscape design system offers comfortable and compact modes. It says, “Users are in control of choosing their preferred level of density within an application,” makes comfortable the default and requires that users can always switch. That last part matters: a setting that’s available only during setup, or only in some parts of the product, doesn’t put control in the user’s hands.

Cloudscape also keeps some things out of compact mode on purpose. Readability items such as alerts, help panels and form validation messages stay out of it. So do interactive controls such as select menus and date pickers.

That distinction is the whole point: density changes spacing, not meaning. It never shrinks warnings, errors or the controls people must hit. Carbon’s smallest row sits exactly at the 24 px target floor. That’s the edge, not a goal. A system can support that compact size without treating it as permission to shrink every clickable thing.

The case for one fixed density

There’s a fair case for one fixed density. Settings add design and testing cost. Most people never change defaults. A team that designs one excellent density can ship faster and more consistently.

That’s a real tradeoff, but it doesn’t settle the question for every product. If a team wants one mode, pick the accessible default and design it well. But a data-heavy tool that experts use all day is exactly where people do change defaults. Their preference for seeing more rows is part of how they use the product, not a decorative choice.

The cost of supporting density choices also changes when the system makes them part of the design. Treat density as a token: a spacing and row-height value in the context layer. Once that’s built in, applying a compact or comfortable mode costs little. Test both modes, and protect the same minimums in each.

Icon lens

In a 24 px row, icons drop to 16 px, so only the silhouette survives. Status in a dense table must be carried by shape, color and text together. In Digital Sanskrit terms, density belongs to the context layer: size and spacing tokens. The glyph layer—the root plus modifier—must not change meaning when the row shrinks. Severity (tivrata) is a separate modifier for exactly this reason: the frame or shape says how serious, so it still reads at 16 px.

Try this

**Goal:** Check that your densest table can be compact without making the page or its controls inaccessible.

**Steps:** 1. Take your densest data table and switch it to your most compact setting. 2. Set the browser to 320 CSS px wide, or zoom a 1,280 px window to 400 percent. 3. Confirm the table scrolls inside its own container while the heading, search and pagination reflow. 4. Turn off color and confirm every status still reads; measure the smallest clickable target.

**Check:** The compact and comfortable versions both pass the same minimums, and no warning or error got smaller.

**Reference:** Digital Sanskrit, Appendix A.9 (Accessibility and proof) and Appendix B.2–B.3 (Responsive web; Desktop-only products).

Sources

[W3C WAI, Understanding WCAG 2.2 Success Criterion 1.4.10: Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow)
[W3C WAI, Understanding WCAG 2.2 Success Criterion 2.5.8: Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)
[IBM Carbon Design System, Data table usage](https://carbondesignsystem.com/components/data-table/usage/)
[AWS Cloudscape Design System, Content density](https://cloudscape.design/foundation/visual-foundation/content-density/)