This is fascinating, because the naive English interpretation of the code and the comment on that WebKit bug don't match the actual structure of the code. Here's the relevant code:

    const isInvokedByMouse = event => event.screenX > 0 || event.screenY > 0;
    const isInvokedByKeyboard = event => isEnterKey(event) || isSpaceKey(event);

Either the code should be deliberate about the fact that (is it a keyboard) and (is it a mouse) are separate booleans, or the code should be structured so that the actual categories are mutually exclusive. For example:

    const isInvokedByMouse = ...

    const eventSource = ... (returns "keyboard" or "mouse")

    const eventSource = ... (returns "keyboard", "mouse", or "not sure")

Seems like a non bug to me.

The first mistake the developer made, was that he wanted to create a different user experience between keyboard and mouse. Stick to what you get by default and design your components so they work for both usecases. Don't try to be smart when it comes to accessibility.

What he ended up doing is what I would have considered a hack. A solution that inevitably breaks or has side effects.

The reason there rarely are good handles to do things differently in accessibility context, is because it's not something that's meant to be handled differently.

Does anyone else find this write up confusing?

My understanding from this is that BBC want slightly different behaviour depending on whether it's a mouse or keyboard "click" (keyboard shouldn't show the animation and should focus the first link in the menu).

However, they also want the ease of binding to a single event and while binding to "click" can do this, they have no way to tell whether it was a mouse click or keyboard press which triggered the event.

To solve this they're using an unreliable heuristic after realising in Chrome if the mouse position is screenX=0, screenY=0 it means the event was either triggered by a mouse click at screenX=0, screenY=0 or a keyboard.

As someone whose worked on accessibility projects in the past, this is a really stupid idea imo, and had I reviewed a PR with something like this I would have asked it to be reworked. While I agree browsers should ideally do the same thing, the real issue here seems to me that screenX and screenY make little sense on "click" triggered by a keyboard.

The solution ideally would be a new event ("trigger" or something) which doesn't emit a "MouseEvent", but something more generic which could apply to both a keyboard and mouse event and provide information about the "trigger" source. Imo keyboard "clicks" are weird to begin with and would ideally be fixed with a more appropriate event.

That said, I understand this doesn't currently exist in the spec and a solution is needed now. Therefore I don't see why they couldn't also bind to a "keydown" event then if the click is triggered alongside the "keydown" on the same element, assume it was a keyboard press. That would be far more reliable and far less hacky than what they're doing, and would allow them to trigger from the single event with a bit of extra code to detect if it was a keyboard or mouse.

While I can understand the author's need for screenX and screenY, the question remains. Why would screenX return the real screenX position instead of the position within the renderer (I don't think that exists?) or the rendered page (layerX and layerY)? The author's need would be met the same with the renderer position and window positions wouldn't be leaked to all visited websites.

> Often when opening a menu, we don't want a slightly different behaviour around focus and animations depending on if the user 'clicks' with a pointer or keyboard.

Is the word “don’t” a mistake which gives the sentence the opposite of the intended meaning?

It seems that querying the screen position is just a heuristic they came up with to determine the nature of the event. Instinctively I would use instance of MouseEvent for this, but even this feels risky/hacky to me.

My question is why they're relying on those heuristics. My guess is that toggleMenu is being used by multiple event handlers. Or maybe there's something else going on that is specific to their codebase.

It's hard to judge without knowing the full picture.

EDIT: Aha, there's an answer here: https://news.ycombinator.com/item?id=42174177

But they're already checking for event.name == 'click' in the revised code. So why would you want to filter out some legitimate click events?

No its not. You can do media select on if the primary input device is a pointer device (and, further, if it has high accuracy) and then filter on that.

I used it to select which layout to show in the past.

If you want to listen to input on touch only then you can do that and call preventDefault on the event so that the browser does not then cause a click event. Or you can just save yourself the trouble and write a click handler.

> As an industry, why haven't we figured out how to make drop downs that consistently open for all users? Is accessibility just that hard? Are there web frameworks/web components BBC should be using that already handle this?

I don't know the answers to all the questions, but "is accessibility just that hard" is a firm, concrete, YES.

Here's some real world examples, modals. If you are not a vision impaired user, you can see what's going on when you're presented with a white box containing ui components swimming in a sea of "don't touch this bit" grey.

If you're using a screen reader there's no guarantee that you'll receive any of that information. When your screen reader controls tab through the UI elements and you land back at the top of the box, will your particular screen reader report that to you? Will it list the available interactable elements? Will it list them in the same order as the other screen readers? How about on phone? How about on Mac? Will your screen reader and browser report the inputs right, or will it silently allow the user to fall out of the modal and back into the rest of the site?

When it comes to accessibility you can't trust that the OS, browser and the screen reader are cooperative, or even that they'll do something sane in the right situation.

In 2019 I had to log a bug with VoiceOver + Safari because a negative CSS margin could cause screen readers to read RTL text blocks out of order. Users with unimpaired vision would see "9/10/2019" and on the screen reader you would hear "ten slash nine slash two-thousand-and-nineteen", as a stopgap measure we had to set the text aria-hidden and put in an invisible p tag there with the correctly ordered text so screen readers wouldn't choke on it.

All this to say, sometimes when you see some jank code relating to accessibility there really isn't a better way to do it. Even if you dumped everything, turned the codebase upside down and focused on accessibility first you'd see stuff inexplicably break the moment JAWS or VoiceOver updates.

Agreed. But ultimately many issues arise when user agents customize these elements in very dubious ways. It's ok for the most part, but there's a reason behind reset.css files, and I wager a more nuclear approach was used here to circumvent these issues completely.

I'm just trying to reason on their decision here.

Actually that is what we're going to do. I'm hoping to merging in code, soon, that will change it to use pointerId === -1 and then fall back to screenX === 0.

At the time this code was originally written four years ago or whenever it was, not all browsers used PointerEvent for click.

I've searched for reasons and couldn't find much. The fact that a website can know where a browser window is located (window.screenX/window.screenY) and that clicks position can be reported in that coordinate system sounds insane for a desktop. TOR Browser seems to spoof screenX and screenY to avoid fingerprinting.

Has anyone seen good use-cases for that feature? I'm thinking about dual window applications that interacts with each other (I think I saw a demo of something like this a while ago on HN but I wasn't able to find it again), or sites where behavior depends on their location on the virtual screen.

It’s useful for creating games where the graphics are composed of many small browser windows which interact with one another.

For example:

https://youtu.be/3al8prbfK5o?si=loNtyqIfMFkppm5V

Because this was easy to do during the 10 days allocated to develop JavaScript in 1995, and then backwards compatibility kicked in :(

If you're reacting to click events, you might want to know the coordinates of where you're clicking. I mostly use this for click and drag stuff since you can get the delta between events and update position of the thing being dragged.

As for why they're checking for coordinates instead of checking for event.type is beyond me. Still I appreciate the write up, it is a good puzzle and relatable to come across code you didn't write and ask, why is it important that the click coordinate is nonzero? Why can't we just check that event.target is the button we want to activate? Why are we using JavaScript at all when a details/summary tag would do the same job?

I use it for a JavaScript-free CAPTCHA, works well, but it only sends the x and y of mouse click upon clicking on it.

Well, I used it for bounding box and reading order annotations, but that’s a pretty specialized use case.

Uh. So they can keep track of what the user is doing?

Why would you just send a document when you can generate a heat map of where the user is on your website. And then complain about the performance and wonder why it costs so much to run a modern website.

Haha. Welcome to the world of analytics. Lots of sites are recording exactly what you are doing on their site including mouse movement at all times.

> Why are you filtering for screen coordinates in the first place?

FTA:

> The isInvokedByMouse was checking whether the click event was invoked by a mouse or touch pointer – rather than a keyboard – by checking if the screenX or screenY coordinates were a positive number.

They were trying to detect whether it was keyboard or mouse activation, and whoever wrote it assumed that screen coordinates of mouse events would always be positive.

`event.detail` [1] is 0 for keyboard “clicks” and 1 for pointer clicks.

1: https://developer.mozilla.org/en-US/docs/Web/API/UIEvent/det...

> Keyboard events don't have a screenX or screenY from what I remember as well.

Remember that this is on 'click' events. The 'click' event type is a bit of a misnomer: it’s arguably more “activate” than “click”, because (depending a little on platform conventions) it also triggers on Space/Enter if the element is focused. But importantly it’s still a 'click' event: so it’s still a PointerEvent, not a KeyboardEvent. Since various of the fields aren’t appropriate, they get zeroed. So, screenX == 0 && screenY == 0 means either that the pointer is at the top left of the screen, or that the event was not generated by a pointer (that is, by a keyboard).

Try it out yourself, if you like, by loading a URL like this and activating by keyboard and by mouse and comparing the events.

  data:text/html,<button onclick=console.log(event)>

Fortunately, there’s a proper fix: `event.pointerId === -1` indicates non-pointer (viz. keyboard) activation.

This is just a heuristic to determine if the event is keydown or click.

In the article the author says that the issue is that the same function is handling both events, and they will work on refactoring it to something better.

The normal approach is just have different functions answering to different events. Or using more precise information about the event [1], instead of a heuristic.

[1] A suggestion was made by this poster: https://news.ycombinator.com/item?id=42174436

Yeah, comparing to zero is still the wrong thing to do, was dissatisfied after reading the article because the problem still isn't really solved.. just swapping one spooky edge case with another.

Who knows, they probably broke the menu for keyboard navigation, voice navigation, eye tracking or something like that. This is one of those cases where you could really "make it make sense" by just using something CSS based.

I appreciate and fully agree with your perspective on this. A thing was treated as if it were some other thing, and acceptably failed to be that other thing.

...because when they are 0 one can infer that the event came from a keypress rather than a mouse. They want to know this.

> Some people shiver at the Mount Everest of clumsy JavaScript code needed to provide a usable web experience.

You don't need any javascript to provide a usable web experience. In fact, you are more likely to break usability with it.