| Hello I am the author and, yes, I totally agree some generic 'trigger' event would be far better. To use the keydown event means we have to assume that the 'Enter' and 'Space' are the only keys we need to check for. Using 'click' is far safer from an accessibility point of view because it will always respect what your device considers to be some kind of input trigger. As stated in the UI Events spec: > For maximum accessibility, content authors are encouraged to use the click event type when defining activation behavior for custom controls, rather than other pointing-device event types such as mousedown or mouseup, which are more device-specific. Though the click event type has its origins in pointer devices (e.g., a mouse), subsequent implementation enhancements have extended it beyond that association, and it can be considered a device-independent event type for element activation. And to be clear, I would not want to do it this way if it was for some really critical difference in behaviour between pointer or keyboard interactions. I'm OK with this strange mechanism here because the fallback behaviour is not that different. If you're on Safari, for example, which can't check for `screenX === 0`, then all that happens is that there will be an animation when you open the menu. However, sadly, because of the ways various developers have added to this code over the years, it's broken that fallback behaviour and stopped it working entirely. So I've just finished a refactor to sort that out and it will hopefully be going live soon. |
I currently have an open semi-related bug, also in a menu dropdown component (where we also want to focus the first item when triggered via keyboard). My issue is that when Windows Narrator is used, the space/enter triggers a mocked click event instead of the keydown. We could check for the position like you do.
Unfortunately, accessibility is often hacky both on the content side, but also on on the browser/screen reader side.