Disabled

When a button can't be pressed yet, there were only two long-standing options. Remove it from the screen, or leave it pressable and show an error when somebody presses it. Both leave the person guessing. Remove it and they never learn the feature is there at all; leave it and they find out why it won't work only after clicking.

Pagedeck's checkout screen was the second kind. Accounts with no card on file could still press the pay button, and pressing it produced a single line reading "your request could not be processed." That line doesn't distinguish a missing card from a bad amount, so the same question arrived about thirty times a month.

Disabled is the third option that sits between those two. It keeps showing that the feature exists while saying, before anyone presses, that it isn't available yet. It belongs to the interaction branch of UI state — the ways one element looks different depending on the situation — and it's defined by what has been taken away from the default state, the way the element looks when nobody has touched it.

Three things have to be settled together before the state is complete.

1. The appearance. Drop the opacity to around 40 percent, or switch it to grey, so it draws less attention than the default state. The contrast between text and background falls at the same time, so dimming it until it can't be read at all defeats the reason you kept it on screen.
2. Blocking the interaction. Pressing does nothing, and the element usually comes out of the keyboard tab order as well. Taking it out of that order means it never receives focus, which means a screen reader never announces that it's there. Where the reason genuinely has to reach the person, leave it reachable by tab so it gets read aloud.
3. The reason. This is the part most often skipped, and skipping it makes people guess no matter how well the first two are built. One line next to or under the button does it. For a dimmed pay button, that line is "add a card first."

When several conditions are doing the blocking, disabled may be the wrong answer altogether. With five fields left to fill and only the button dimmed, nobody can tell which one is missing. In that case it works better to leave the button live and point at the missing fields the moment it's pressed.

"Why is this button grey? There's no reason given anywhere."

The state got built and the slot for explaining it was left empty.

"With five conditions, let's not dim it — tell them what's missing when they press."

Proposing a change to how the blocking works at all.

"It's disabled and tab skips it, so for a screen reader that button doesn't exist."

Visible on screen, absent from assistive technology.

At Pagedeck, Noa always attaches one disabled version when handing over a button. The first thing Theo asks about is the reason line, so implementation doesn't start without it.