Skip to content

SheetArticle

Measure68ch · bone, not white

Filed underAccessibility · Testing · Design systems

Published2026-08-09

9 August 2026 · 8 min

Seven defects a gate found that reading the code didn't

Every one of these was in code I'd written, reviewed and shipped. None of them surfaced until something existed whose only job was to fail me.

There's a category of defect that reading the code won't find, and it isn't the subtle ones. It's the ones where the code says what you meant and the runtime does something else entirely. You read the intent back to yourself and it agrees with you. Of course it does, you wrote both of them.

Seven of these came out of one audit pass, all reproduced and all fixed. I'm listing them because the pattern is more useful than any single fix.

The seven

  • Sheet produced an unnamed dialog: a dialog role and aria-modal true, with no aria-labelledby, and SheetTitle wired to nothing. That's 4.1.2, affecting every sheet in the system, mobile navigation included.
  • MobileMenu marked the current destination by colour alone whenever items were driven by onClick rather than href, because aria-current sat on the link branch only, which is 1.4.1.
  • AlertDialog nested two dialog roles, and the outer one, the one carrying aria-modal, had no accessible name. An accessible-name assertion passed against the inner one while axe caught the outer.
  • The rich text editor toolbar states had never worked. Not once, in any build, since the day it was written, because it read the selection during render and held no state and ran no effects, so nothing re-rendered when the selection moved. Bold and Italic lit up when a parent happened to re-render for its own reasons. Which looks like it working, occasionally.
  • Lightbox couldn't be rendered by a consumer at all, it needs a React Aria OverlayProvider ancestor and throws without one. It worked inside this repo's shell and threw everywhere else, including in a unit test.
  • DatePicker never called preventDefault for Enter, Space or Escape. The assignment was dead code sitting after an early return, so Space scrolled the page instead of picking a date.
  • Skip links rendered as an invisible one by one pixel box on 37 routes, because a hand-written screen-reader-only rule with an important flag beat the focus style meant to reveal them. Removing the important flag didn't fix it either, and cascade layers beat it again.

The last of those is the one worth running rather than reading, because the second half of it surprises people who know the cascade well:

Run it

Why removing the !important did not help

A skip link is the first thing a keyboard user meets and it was invisible on 37 routes. Pick a fix, then focus the link and watch which declaration wins.

Fix applied

The link is here. 1px by 1px.

Tab to the link above, or click it, to give it focus.

.sr-only { clip-path: inset(50%) !important }unlayered

.skip-link:focus { clip-path: none }in @layer components

The sr-only rule carries !important. It wins, and the link stays a one by one pixel box even while focused.

What they have in common

Three of the seven passed a test that was pointed at the wrong element. AlertDialog is the clearest case of it. The assertion was real, and it ran, and it went green, and the whole time it was measuring the inner dialog while the outer one carried the modal semantics. A test asserting the right property against the wrong node is indistinguishable from a passing test.

Two of them worked in exactly one environment, which is the worst way for something to be broken, because Lightbox worked in the repo shell and nowhere else and the editor worked whenever a parent happened to re-render for unrelated reasons. Both would have looked fine to me every single time I checked, because I was checking them in the one place they worked.

You don't find these by reading code. You find them by writing something whose entire job is to fail you, and then running it.

The two remaining are the most ordinary and by a distance the most annoying. Dead code sitting after an early return, and a specificity fight that a hand-written utility won twice in a row. Neither is clever and neither took more than a minute to fix. Both shipped, and both sat there for months looking exactly like working code, because that's what working code looks like right up until somebody runs it.

The skip link one is the one I think about, and it's the first thing a keyboard user meets on any page. Mine was a one pixel box on 37 routes, and it had a focus style written specifically to reveal it, sitting right there in the file, doing nothing. Like fitting a fire door and then putting a wardrobe in front of it.

I'll concede the obvious objection and it's a fair one, a code review should have caught at least three of these and it should have caught them early. It should have, and I reviewed them. I wrote most of them and then reviewed them, which is its own kind of comedy.

But review reads intent, and every single one of these had perfectly correct intent written down in it. The dialog meant to have a name, the menu meant to mark the current page, and the toolbar meant to update. You read it back and it agrees with you, because you're reading the thing you meant rather than the thing that runs. What was missing was never a better reviewer, it was anything at all that ran the code and disagreed.

No share buttons, no claps, no newsletter thing sliding up from the bottom. If it's any good you'll send it to somebody yourself, and if it isn't then a row of icons was never going to fix that.