- Ya
- 5 Septemba 2026, 02:59 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 2c9cbb3
Three things the screen was getting wrong, all found by looking at it rather than by running it. The bar was a TALLY of failures, wrapping every five segments. The gaps between rungs are not five — they are six, then four, then ten, ten, ten — so at eleven failures it showed one of five filled, implying four attempts left, directly under a line correctly reading "9 more attempts". The bar is the half people glance at, so it was the half more likely to be believed. It is now a PROXIMITY meter: it fills as the next lockout approaches and empties once one is crossed. An empty bar means "more than five away", and the caption says which. Anyone within five attempts of a permanent block was told "signing in pauses for permanent." No duration finishes that sentence, so the sentence changes: the server now sends the next rung's name alongside its label, and the meter reads "5 more attempts before this device is blocked." Carried as a flag rather than sniffed out of the label, which would break the day the label is translated. The countdown digits are now aria-hidden. The lockout panel is a role="alert", so a number changing four times a second was four announcements a second, burying the sentence explaining what was happening. A static "about 15 minutes" line carries the same information once — rounded up, because a screen reader has no way to watch a number change and a second-accurate figure is stale before it finishes being read. Also moves the meter clear of the password field's error glow, where its segments read as part of the field rather than as a meter of their own. Adds the cross-repo design doc for the whole feature, including the reasoning that is hard to recover from the code: why the subject is the (address, identifier) pair, why the blocked marker and the notify claim must be separate Redis keys, and why the client owns the countdown and no part of the policy.