Anneke

One thing that gets missed in this debate and matters a lot: live validation is far more disruptive for screen reader users than it looks on screen.

If the error message is in a live region, every keystroke that changes validity announces something. The user is trying to hear what they are typing and instead hears repeated interruptions. What reads as a small red hint visually is a constant interruption aurally.

So the on-blur pattern is not only better UX in the general case, it is substantially better for assistive technology. And when you do show the error, associate it with the field programmatically rather than only placing it nearby: otherwise a user who tabs back into the field is told the field is invalid with no indication of why.

Add a label. That is the whole recommendation and it survives every context I have tested in.

The usual objection is space, and it is worth pushing back on, because in your case the cost of failure is very high. This is a dietary preference control. Somebody avoiding an allergen who does not find this control does not have a slightly worse experience - they scroll a menu that is mostly irrelevant to them, or worse, they order something they should not have.

For safety-relevant filtering I would go further than a label on an icon. Make it a visible, worded control: "Dietary filters" as text, in the flow, not tucked into an icon row. The people who most need it are the least likely to go hunting.

And whatever you do, give it an accessible name. An unlabelled icon button is announced as "button" and nothing else.

Whichever wording you land on: move focus into the dialog when it opens, put it on the safe button, trap focus inside while it is open, and return focus to where it was when it closes.

A warning dialog that a keyboard user can tab behind is worse than no dialog, because it blocks the interface while being unreachable. This is the most common bug I find in exactly this pattern, and it is invisible unless you unplug the mouse.

The accessibility case is even more clear-cut, because hover simply does not exist for a large fraction of users.

• Touch devices have no hover. Whatever you build has to have a tap equivalent, so you are maintaining two interaction models for one control.
• Keyboard users move focus, not a pointer. If navigation happens on hover only, keyboard users get a different app; if you make it happen on focus too, then tabbing through the menu navigates repeatedly, which is far worse.
• Users with motor impairments frequently cannot hold a pointer still. Tremor, an unsteady grip or a head-pointer means the cursor drifts across whatever is nearby. An interface that acts on incidental hover is close to unusable for them.

Hover is fine for revealing information: a submenu, a tooltip, a preview. It is not fine for committing to an action, and navigation is an action.

The accessibility argument arrives at the same fix by a shorter route: never encode meaning in colour alone, brand collision or not.

Around one in twelve men has some form of colour vision deficiency, and red-green is by far the most common. A green dot and a red dot are, for a meaningful fraction of your users, two dots. Everything else - greyscale printing, bright sunlight on a phone, a cheap monitor, a screen reader: degrades colour-only signals too.

So status needs a second channel regardless. Word, icon shape, position, or all three. Once you have done that for accessibility reasons, the brand collision is already solved as a side effect, which is a nice case of the two concerns pointing the same way.

One practical tip: use different shapes for status, not just different colours. A filled circle for running, a hollow circle for stopped, a triangle for warning. Distinguishable with no colour perception at all.

Two things to check that are easy to miss.

Some assistive technology uses find-in-page as a navigation mechanism. Overriding it can remove a route through your content that somebody depends on, and they will not report it as a bug: they will just stop using your app.

Do not intercept while focus is in a text field. People use the key combination inside inputs for other things depending on their platform and configuration, and an app-level handler that fires regardless of focus is a constant low-level annoyance.

And offer a setting to disable the override. It costs almost nothing and it converts your riskiest decision into a preference.