4 ms·

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

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.
- joshtumath 2y ago
  Well said! It certainly applies to web development as well. Sadly, sometimes more complex solutions are needed - especially when based on user research.
- hinkley 2y ago
  Also note, it’s been about 10-15 years since the rules changed and if you want to work on a government contract, accessibility is mandatory.
- O-stevns 2y ago
  Of course there are edge cases, I work with accessibility too, for an app in the public sector where WCAG rules are no joke, so I know this as well but even so, we don't build custom accessibility UI for our users. We (try to) build the UI with accessibility in mind so it's scalable, can be used and navigate properly by voice over and keyboard. On mobile it's not perfect either but in general you do have features to change stuff like. focus, grouping of elements, how the keyboard navigate the view stack, how to access a button through custom actions and like you mention, change the tab index programmatically. Even so, not everything can be fixed or handled through standard accessibility means and as such hacks will inevitably make it into the products. I get what you're saying but I still think that making things accessible and designing with common accessibility in mind should be default and as such it has to be thought about when designing and developing from the get go. Having to create custom interfaces to fulfill a specific need might be a good fit for some things but not when developing apps and websites unless you're targeting that user-group specifically.
joshtumath 2y ago
I am the author. > 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. We have. The behaviour is mostly the same whether you're using the keyboard or a pointer (mouse/touch/pen). The only difference is that, for keyboard users, we want to turn off the animation and move the focus to the first link in the menu instead of focussing on the menu's parent <ul>. The problem was that, as various devs have iterated on the menu over the years, it's broken the fallback behaviour. For my colleague on the funny multi-monitor set up, it should have fallen back to the keyboard no-animation behaviour with no real major difference to the UX, but instead it fell back to the no-JS experience. So yes, generally don't try to be smart with accessibility, avoid ARIA attributes except where necessary, etc, but click events are the universal input event and work on any kind of input device and have perfect browser support. It's far better for accessibility using them instead of a mix of keydown and mousedown or pointerdown, and potentially missing other kinds of input events. As I stated in another comment, if it was a scenario where there needs to be a major difference in behaviour between keyboard and pointers, then I would rather use separate keydown and pointerdown events.
- O-stevns 2y ago
  The _mostly_ same behavior is what caused the problem though :P I'm curious, did these solutions come to pass because you had to make adjustments based on actual user feedback or was it just a developer trying to think ahead? I'm questioning whether forcing the user to tab to get to the menu item is a hindrance at all or whether the animation was a problem. Maybe the former could have been solved using ARIA tags or maybe it would require bigger changes to the component itself. Accessibility is a roller-coaster for all these reasons alone.
- abtinf 2y ago
  > we want to turn off the animation and move the focus to the first link in the menu instead of focussing on the menu's parent Why not just always turn off the animations? Why not just always move the focus to the link? What is the benefit of the animation to the user? What is the benefit of focusing on the menu’s parent to the user? One rule of thumb with accessibility is that accessible products are usually better for everyone.
that_guy_iain 2y ago
> The first mistake the developer made, was that he wanted to create a different user experience between keyboard and mouse. No, they wanted to make them the same. It's just to give a blind person the same experience as a seeing person requires different things because they operate differently for obvious reasons. For example, a blind person can't see when an animation has finished. They expect that menu to be available once they've triggered it. However, seeing people see the dropdown appearing and then go to use it once it's ready. > Don't try to be smart when it comes to accessibility. In all seriousness, considering the state of accessibility as is, I think going outside the box isn't trying to be smart. It's actually being smart. The BBC frontend team is probably at the forefront of making high-traffic websites extremely usable.
- pwg 2y ago
  > For example, a blind person can't see when an animation has finished. They expect that menu to be available once they've triggered it. However, seeing people see the dropdown appearing and then go to use it once it's ready. For my two-cents, the BBC was simply trying too much to be "cutesy". Don't animate anything, because the silly animation on mouse click simply makes the website feel slower overall. Just open the menu as fast as the user's browser will open it.
  - unclad5968 2y ago
    That wouldn't change anything. They want the first element of the menu to be focused when "clicked" from a keyboard but not from a mouse. The animation doesn't affect that.
  - j16sdiz 2y ago
    > Don't animate anything Animation helps to correlate screen elements. Without animation it actually takes longer to establish the mental relationship between the action and the result.
    - hombre_fatal 2y ago
      We as developers think we like zero animation. Probably not least because animation is harder for us to implement than just view(state). But it's very easy to create cases where the UX sucks because things happen instantly especially as inherent complexity of the app increases.
cryptonector 2y ago
I think there is no browser bug here, though using negative screen coordinates is probably going to be surprising to a lot of folks. However, the BBC's intent seems quite sound to me from an a11y point of view, and their commitment to a11y is commendable. Though it's likely that for some browsers their attempts at defining their own a11y experience will result in a bad UX anyways.

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.

joshtumath 2y ago
Well said! It certainly applies to web development as well. Sadly, sometimes more complex solutions are needed - especially when based on user research.
hinkley 2y ago
Also note, it’s been about 10-15 years since the rules changed and if you want to work on a government contract, accessibility is mandatory.
O-stevns 2y ago
Of course there are edge cases, I work with accessibility too, for an app in the public sector where WCAG rules are no joke, so I know this as well but even so, we don't build custom accessibility UI for our users. We (try to) build the UI with accessibility in mind so it's scalable, can be used and navigate properly by voice over and keyboard. On mobile it's not perfect either but in general you do have features to change stuff like. focus, grouping of elements, how the keyboard navigate the view stack, how to access a button through custom actions and like you mention, change the tab index programmatically. Even so, not everything can be fixed or handled through standard accessibility means and as such hacks will inevitably make it into the products. I get what you're saying but I still think that making things accessible and designing with common accessibility in mind should be default and as such it has to be thought about when designing and developing from the get go. Having to create custom interfaces to fulfill a specific need might be a good fit for some things but not when developing apps and websites unless you're targeting that user-group specifically.

joshtumath 2y ago

I am the author. > 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. We have. The behaviour is mostly the same whether you're using the keyboard or a pointer (mouse/touch/pen). The only difference is that, for keyboard users, we want to turn off the animation and move the focus to the first link in the menu instead of focussing on the menu's parent <ul>. The problem was that, as various devs have iterated on the menu over the years, it's broken the fallback behaviour. For my colleague on the funny multi-monitor set up, it should have fallen back to the keyboard no-animation behaviour with no real major difference to the UX, but instead it fell back to the no-JS experience. So yes, generally don't try to be smart with accessibility, avoid ARIA attributes except where necessary, etc, but click events are the universal input event and work on any kind of input device and have perfect browser support. It's far better for accessibility using them instead of a mix of keydown and mousedown or pointerdown, and potentially missing other kinds of input events. As I stated in another comment, if it was a scenario where there needs to be a major difference in behaviour between keyboard and pointers, then I would rather use separate keydown and pointerdown events.

O-stevns 2y ago
The _mostly_ same behavior is what caused the problem though :P I'm curious, did these solutions come to pass because you had to make adjustments based on actual user feedback or was it just a developer trying to think ahead? I'm questioning whether forcing the user to tab to get to the menu item is a hindrance at all or whether the animation was a problem. Maybe the former could have been solved using ARIA tags or maybe it would require bigger changes to the component itself. Accessibility is a roller-coaster for all these reasons alone.
abtinf 2y ago
> we want to turn off the animation and move the focus to the first link in the menu instead of focussing on the menu's parent Why not just always turn off the animations? Why not just always move the focus to the link? What is the benefit of the animation to the user? What is the benefit of focusing on the menu’s parent to the user? One rule of thumb with accessibility is that accessible products are usually better for everyone.

that_guy_iain 2y ago

> The first mistake the developer made, was that he wanted to create a different user experience between keyboard and mouse. No, they wanted to make them the same. It's just to give a blind person the same experience as a seeing person requires different things because they operate differently for obvious reasons. For example, a blind person can't see when an animation has finished. They expect that menu to be available once they've triggered it. However, seeing people see the dropdown appearing and then go to use it once it's ready. > Don't try to be smart when it comes to accessibility. In all seriousness, considering the state of accessibility as is, I think going outside the box isn't trying to be smart. It's actually being smart. The BBC frontend team is probably at the forefront of making high-traffic websites extremely usable.

pwg 2y ago
> For example, a blind person can't see when an animation has finished. They expect that menu to be available once they've triggered it. However, seeing people see the dropdown appearing and then go to use it once it's ready. For my two-cents, the BBC was simply trying too much to be "cutesy". Don't animate anything, because the silly animation on mouse click simply makes the website feel slower overall. Just open the menu as fast as the user's browser will open it.
- unclad5968 2y ago
  That wouldn't change anything. They want the first element of the menu to be focused when "clicked" from a keyboard but not from a mouse. The animation doesn't affect that.
- j16sdiz 2y ago
  > Don't animate anything Animation helps to correlate screen elements. Without animation it actually takes longer to establish the mental relationship between the action and the result.
  - hombre_fatal 2y ago
    We as developers think we like zero animation. Probably not least because animation is harder for us to implement than just view(state). But it's very easy to create cases where the UX sucks because things happen instantly especially as inherent complexity of the app increases.

cryptonector 2y ago

I think there is no browser bug here, though using negative screen coordinates is probably going to be surprising to a lot of folks. However, the BBC's intent seems quite sound to me from an a11y point of view, and their commitment to a11y is commendable. Though it's likely that for some browsers their attempts at defining their own a11y experience will result in a bad UX anyways.