The bug only one user could see was an accessibility bug

Why mixing fixed and fluid column widths makes data table columns disappear on smaller screens, and what that means for people who zoom

In Microsoft Edge at 1280 × 1024, three columns collapsed to thin slivers. Their data was still in the page, but nobody could see it. (Recreated example with sample data.)

Every designer and front-end developer has met the “ghost bug.” Only one user sees it. It doesn’t show up on your machine, in dev or in production. Everyone else says the screen looks fine.

I ran into one during a live stakeholder event. A user reported that some columns in one of our data grids were missing. Between the Display Order and Modified On columns, there was only a thin sliver where the Description column should have been. The last two columns in the grid had the same problem.

I tested it on my machine. Our QA team tested it. I asked another developer to try it on his machine, and my manager tried it on theirs. We checked our QA and pre-production environments too. Every column was there, every time.

The answer wasn’t in the code at first. It was in the user’s setup.

One screen setting, one browser

The user was working on a monitor set to:

• Resolution: 1280 × 1024
• Display scale: 100%
• Browser zoom: 100%
• Browser: Microsoft Edge

The browser was the part that made this so hard to track down. The bug only happened in Edge. In Chrome, on the same screen settings, the grid looked fine. Edge and Chrome are built on the same engine, so we didn’t expect them to behave differently. But small differences between browsers, such as scrollbar width or default settings, can change the available space by a few pixels. When a layout is already at its limit, a few pixels is enough to break it.

The screen size itself is not unusual. It’s a common setting on older monitors and on screens in shared offices. But it gives the browser about 1280 pixels of width to work with, much less than a typical 1920px screen.

At that width, three columns had all but vanished. Their headers were gone, their filter icons were squeezed up against the neighboring columns, and their cells looked empty.

The data was there the whole time

When I inspected one of the empty Description cells in the browser’s developer tools, the text was right there in the page. The cell was 0.48 pixels wide.

The cell’s CSS made the text invisible. It used three common settings that keep long text tidy on a single line:

• white-space: nowrap keeps the text on one line instead of wrapping.
• overflow: hidden hides any text that doesn't fit in the cell.
• text-overflow: ellipsis shows "…" where the text gets cut off.

Normally, that means a long description shows as “Main session for regist…”. But with less than half a pixel of width, nothing fits, not even the “…”. So the cell looked completely empty.

Get Sampada Phadnis’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

So the question wasn’t “why is the data missing?” It was “why is this column less than a pixel wide?”

What I found in the grid

Our app uses an Angular data grid (Kendo UI). Here’s a simplified version of the column setup:

<kendo-grid-column field="attributeType" title="Attribute Type" [width]="150">
<kendo-grid-column field="attribute"     title="Attribute"      [width]="200">
<!-- ...more columns with set widths... -->
<kendo-grid-column field="description"   title="Description">
<kendo-grid-column field="notes"         title="Notes">
<kendo-grid-column field="status"        title="Status">

Most columns had a set width. The three that disappeared had none. That mix was the problem.

Why mixing fixed and fluid widths breaks

When some columns have a fixed width and others don’t, the grid works out the layout like this:

1. Give every fixed column its exact width.
2. Split whatever space is left among the columns without a width.

On a wide screen, there’s plenty left over, so the fluid columns look fine. On a narrower screen, the fixed columns still take their full width, so almost nothing is left. The fluid columns shrink to less than a pixel. Their content is still there, but there’s no room to show it.

Set widths stay the same at every screen size. Only the leftover space shrinks, so the columns without a width take the hit.

The design looked fine on our screens because we were all testing on wide monitors.

The fix: give every column a width

The fix was small. I set a width on every column:

<kendo-grid-column field="description" title="Description" [width]="200">
<kendo-grid-column field="notes"       title="Notes"       [width]="200">
<kendo-grid-column field="status"      title="Status"      [width]="100">

Now the grid knows its total width. When the screen is narrower than that, it shows a horizontal scrollbar instead of shrinking columns until they disappear. Every column, header and filter stays visible.

With a width on every column, the grid scrolls sideways instead of collapsing. (Recreated example with sample data.)

One tradeoff to check: If every column has a fixed width and they add up to less than a very wide screen, some grids leave empty space on the right. Check wide screens too. Depending on your grid, you can fix this by setting minimum widths or by letting one column grow.

Why this is an accessibility issue, not just a layout bug

Here’s the part I almost missed. A 1280px screen isn’t the only way to end up with a narrow viewport. Zooming in does the same thing.

When someone zooms their browser to 200% on a 1920px monitor, the page has only about 960 pixels of width to lay out. On a 1280px screen at 200%, it’s about 640. Many people with low vision use browser zoom every day. For them, a grid that only breaks on a narrow screen isn’t an edge case. It’s what they always see.

Two WCAG success criteria apply here:

• 1.4.4 Resize Text (AA): text must work at 200% zoom without losing content or functionality. Columns that shrink until their content disappears fail that.
• 1.4.10 Reflow (AA): content should fit narrow viewports without scrolling in two directions. Data tables are an exception, because their rows and columns need a two-dimensional layout. So a horizontal scrollbar on a data grid is an accepted, accessible pattern. Columns that vanish are not.

There’s one more twist. Because the text was still in the page, a screen reader could still read it, while sighted users saw nothing. The same screen gave different people different information, and nobody on the team could tell.

After the fix, I tested the grid at 200% browser zoom. Every column stayed visible, and the table scrolled sideways as expected.

What we test now

This bug changed how our team tests data tables. You can’t catch it in a design file, so these are now test scenarios for every grid we build:

• Test at 1280px wide, not just at your own screen size.
• Test in every supported browser, including Edge. Don’t assume Chrome and Edge behave the same.
• Test at 200% browser zoom on a normal monitor.
• Test with Windows display scaling at 125% and 150%, which many laptops use by default.
• If a cell looks empty, inspect it. The data may be there with no room to show it.

Design still has a part to play. In the spec for any data table:

• Say how each column should size: fixed, minimum or flexible. Don’t leave it to the grid’s defaults.
• Decide what happens when space runs out: scroll, wrap or hide columns. Design that state on purpose.

The takeaway

Ghost bugs usually aren’t random. They happen when a layout that’s flexible in some places and rigid in others meets a screen we didn’t test. For data tables, being clear is the accessible choice: give every column a width and let the table scroll.

The user who reported this bug wasn’t on an unusual setup. They were showing us a screen we hadn’t designed for. Many other users, including everyone who zooms, see that screen every day.

What’s the strangest screen setup a user has reported a bug from? I’d love to hear your ghost bug stories in the comments.