6 ms·

For anyone who didn't click through to the WebKit bug report the author submitted, a WebKit dev asked him to clarify why the BBC finds it beneficial to be able

For anyone who didn't click through to the WebKit bug report the author submitted, a WebKit dev asked him to clarify why the BBC finds it beneficial to be able to detect that the event was sent from a keyboard. This is the author's response: > Ironically, I want interoperability on this to help with use cases relating to accessibility. > I work at the BBC and, on our UK website, our navigation bar menu button behaves slightly differently depending on if it is opened with a pointer or keyboard. The click event will always open the menu, but: > - when opening with a pointer, the focus moves to the menu container. > - when opening with a keyboard, there is no animation to open the menu and the focus moves to the first link in the menu. > 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. > The 'click' event is great when creating user experiences for keyboard users because it is device independent. On keyboards, it is only invoked by Space or Enter key presses. If we were to use the keydown event, we would have to check whether only the the Space or Enter keys were pressed. Source: https://bugs.webkit.org/show_bug.cgi?id=281430 https://bugs.webkit.org/show_bug.cgi?id=281430

Sayrus 2y ago
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.
tshaddox 2y ago
> 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?
- joshtumath 2y ago
  Hello I am the author and that was indeed a mistake. Whoops!
O-stevns 2y ago
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.
- f1shy 2y ago
  > Don't try to be smart when it comes to accessibility. “Don't try to be smart” alone is good advice in general and everywhere. Also in UI “don’t try to be original”
  - afandian 2y ago
    The BBC site has a "search box" that's actually a button that brings up the real search box. Always feels confusing. At least it's consistent across News / Sounds / iPlayer.
    - eCa 2y ago
      This is becoming more and more common. Can’t say I’m a fan either.
  - josephg 2y ago
    I prefer the line: “make it as simple as possible, but no simpler” Sometimes complexity is simply the right tool for the job. Complexity is essential and valuable in all sorts of places - like fuzzers, LLMs, compilers, rendering engines, kernel schedulers and so on. But projects only have so much complexity budget to spend. I think I've spent my whole career trying to figure out how to spend complexity wisely. And I could spend decades more on it.
- willwade 2y ago
  See I work in accessibility. Like I provide and create solutions direct to end users with complex needs. Not regular web accessibility. I get the view of this. It’s the same idea of universal access. But actually I don’t fully agree. Yes. If you can stick to this principle - and do try / but I promise you edge cases - which in itself is what accessibility users are all about - cause headaches. At some level you have to do custom stuff. It’s the best way. Take for example switch users. Yes. If your ui is tab able - great. But what if you need your items scannable in frequency order. Your tab index needs to change to meet the end users needs. Or eye gaze users. The accuracy level changes. Add in cognitive issues. You can’t just make a one size fits all interface. At some stage you need to significantly customize it. You can’t rely on a user just learning a complex system level interaction technique- if they can’t do that you have to customise on an individual level.
kypro 2y ago
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.
- joshtumath 2y ago
  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.
amluto 2y ago
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); Ignoring the actual conditions entirely, this code seems to be trying to categorize the event into one of two categories: mouse or keyboard. But what it actually does is to categorize into one of four categories: (mouse and not keyboard), (keyboard and not mouse), (keyboard and mouse), and (neither keyboard nor mouse). And, as the original bug shows, (neither keyboard nor mouse) is handled inappropriately. One might wonder whether (keyboard and mouse) works well. 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 = ... and use !isInvokedByMouse to check for keyboardiness, or: const eventSource = ... (returns "keyboard" or "mouse") or, perhaps even better: const eventSource = ... (returns "keyboard", "mouse", or "not sure")
- nightpool 2y ago
  This is a great comment ^ whenever you use two booleans like this, you're opening yourself up to "unrepresentable state" logic errors. Finding and noticing this in code can be tricky, but it's a great example of something that should be caught during code review.
  - politelemon 2y ago
    Not sure if exactly the same thing but reminds me of "Booleans are a trap" https://katafrakt.me/2024/11/09/booleans-are-a-trap/ https://katafrakt.me/2024/11/09/booleans-are-a-trap/
    - iwontberude 2y ago
      Yet another article prematurely optimizing. It’s like these people have nothing better to do. I’ll wait for my code to get into stupid edge cases first and then fix it. Even if you spend your time avoiding booleans you will still find yourself with some new contradictory state and have to fix it differently anyways.

Sayrus 2y ago

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.

tshaddox 2y ago

> 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?

joshtumath 2y ago
Hello I am the author and that was indeed a mistake. Whoops!

O-stevns 2y ago

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.

f1shy 2y ago
> Don't try to be smart when it comes to accessibility. “Don't try to be smart” alone is good advice in general and everywhere. Also in UI “don’t try to be original”
- afandian 2y ago
  The BBC site has a "search box" that's actually a button that brings up the real search box. Always feels confusing. At least it's consistent across News / Sounds / iPlayer.
  - eCa 2y ago
    This is becoming more and more common. Can’t say I’m a fan either.
- josephg 2y ago
  I prefer the line: “make it as simple as possible, but no simpler” Sometimes complexity is simply the right tool for the job. Complexity is essential and valuable in all sorts of places - like fuzzers, LLMs, compilers, rendering engines, kernel schedulers and so on. But projects only have so much complexity budget to spend. I think I've spent my whole career trying to figure out how to spend complexity wisely. And I could spend decades more on it.
willwade 2y ago
See I work in accessibility. Like I provide and create solutions direct to end users with complex needs. Not regular web accessibility. I get the view of this. It’s the same idea of universal access. But actually I don’t fully agree. Yes. If you can stick to this principle - and do try / but I promise you edge cases - which in itself is what accessibility users are all about - cause headaches. At some level you have to do custom stuff. It’s the best way. Take for example switch users. Yes. If your ui is tab able - great. But what if you need your items scannable in frequency order. Your tab index needs to change to meet the end users needs. Or eye gaze users. The accuracy level changes. Add in cognitive issues. You can’t just make a one size fits all interface. At some stage you need to significantly customize it. You can’t rely on a user just learning a complex system level interaction technique- if they can’t do that you have to customise on an individual level.

kypro 2y ago

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.

joshtumath 2y ago
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.

amluto 2y ago

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); Ignoring the actual conditions entirely, this code seems to be trying to categorize the event into one of two categories: mouse or keyboard. But what it actually does is to categorize into one of four categories: (mouse and not keyboard), (keyboard and not mouse), (keyboard and mouse), and (neither keyboard nor mouse). And, as the original bug shows, (neither keyboard nor mouse) is handled inappropriately. One might wonder whether (keyboard and mouse) works well. 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 = ... and use !isInvokedByMouse to check for keyboardiness, or: const eventSource = ... (returns "keyboard" or "mouse") or, perhaps even better: const eventSource = ... (returns "keyboard", "mouse", or "not sure")

nightpool 2y ago
This is a great comment ^ whenever you use two booleans like this, you're opening yourself up to "unrepresentable state" logic errors. Finding and noticing this in code can be tricky, but it's a great example of something that should be caught during code review.
- politelemon 2y ago
  Not sure if exactly the same thing but reminds me of "Booleans are a trap" https://katafrakt.me/2024/11/09/booleans-are-a-trap/ https://katafrakt.me/2024/11/09/booleans-are-a-trap/
  - iwontberude 2y ago
    Yet another article prematurely optimizing. It’s like these people have nothing better to do. I’ll wait for my code to get into stupid edge cases first and then fix it. Even if you spend your time avoiding booleans you will still find yourself with some new contradictory state and have to fix it differently anyways.