Verifying a fix at an extreme setting found a second bug

Last one from this accessibility pass on Deep Cut Atlas: I went to verify a fix, and the verification step turned up an unrelated bug I wasn’t looking for.

The task was supposed to be simple: check whether text truncates okay at the largest iOS accessibility text size (the “XXXL” setting past the normal Dynamic Type range, one step below the actual accessibility-specific sizes some people rely on). Album and track titles were the expected suspects - and they behaved exactly as expected, cutting off cleanly with an ellipsis. Boring, in a good way.

Then I looked at the little colored “Album” / “EP” / “Single” pill badge I’d just fixed for a contrast issue a few minutes earlier. At this text size, it wrapped to two lines inside its rounded capsule, and the word “Album” got hyphenated mid-word: “Al-bum” stacked on top of itself, with the little color dot floating oddly to one side. It didn’t look like scaled-up text. It looked broken - like a bug report screenshot.

The cause: I’d never put a line limit on that text. Most of my text fields had one already (from earlier passes), so I didn’t think to check this specific field - it’s short (one word), so it never occurred to me it needed protecting from wrapping. Turns out “short” and “won’t wrap” aren’t the same claim once the user’s text size is 3-4x normal.

One line fixed it: force the badge to stay on one line, same as everything else, so it truncates instead of wrapping.

Lesson: I went looking for a known category of problem (long text getting cut off) and found a different one (short text wrapping unexpectedly) purely because I was actually looking at the screen instead of reasoning about it in the abstract. “This field is too short to ever need a line limit” was a real assumption I made, and it was wrong. Test at the actual extreme setting, not just your mental model of what the extreme setting does.