[UI/Accessibility] Inconsistent click handlers
What is wrong?
What triggers on mouse-down:
Sidebar: thread item
Sidebar: new chat button
Sidebar: user avatar (that opens the dropdown with settings, feedback and sign out buttons)
Sidebar: new profile form → Copy Settings From dropdown
Chat input: reasoning effort selector
Corner menu buttons: settings button
User/Assistant Message: Branch Off and Retry Message buttons
User Message: chat input actions → dropdown button
Settings → Customization: active profile field → dropdown menu
Settings → Customization: main text font field → dropdown menu
Settings → Customization: code font field → dropdown menu
Settings → History & Sync: chat history section → dropdown button
Settings → History & Sync: chat history section → thread history table → table row + checkbox in it
Settings → History & Sync: shared threads table → table row (not the button on it)
Settings → Models: dropdown button
Settings → Models: filter dropdown button
Settings → Attachments: attachments table → file type filter dropdown button
Settings → Attachments: attachments table → table row + checkbox in it
Why is this wrong?
Click-to-select, click-to-open, click-to-navigate and similar interactions are meant to require a full click cycle: mouse-down and mouse-up. And while none of these are critical, having them immediately trigger on mouse-down makes it impossible for the user to abort the interaction (mouse-down → move mouse away → mouse-up elsewhere). Mouse-down should only trigger something when the expected next action is holding the button (which, I think, none of these match) or when mouse dragging starts (which none of these currently implement).
Log in to comment and vote
Comments5
Mark Florkowski
This is an intentional design decision to make interactions feel “snappier”.
Can you elaborate on how this is an accessibility concern? I am happy to rethink this if it is actively harming users.
None of the listed actions are destructive, so I am less sure of the cause for concern
Silver River
Yes, while none of the actions are destructive, this still violates the principle of cancellability, there's a decent amount of people with limited fine motor control and people using alternative pointing devices like a stylus who rely on being able to cancel an action that is being made on a wrong target.
Another, a more common failure mode is touchscreens… I can't even count how many times I've regenerated a response with a wrong model (which can absolutely end up an expensive one) because the model changer dropdown in the retry message button triggers on mouse-down/touch-start, not on click. This would be less of a concern if there was a mobile app, but until it's out, I'd say that all these issues should be fixed
Let me know if you think any of my points are wrong
Mark Florkowski
Good callout on the retry menus, those selections probably should be on-click - will make sure that gets fixed. The menu itself opening is still probably best left on mouse-down.
Silver River
The post is marked as completed, but the issue with retry/branch menus on touchscreens is still present (haven't checked on desktop)
Mark Florkowski
hm it was workign in dev, but seems to not be in prod. will have a closer look later today