A BBC navigation bar component broke depending on the external monitor

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.

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.

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

> What is the benefit of the animation to the user?

Animations enhance experience by drawing attention to state changes and providing intuitive feedback to user actions.

If you don't find them engaging or useful, that's fine - and you can set prefers-reduced-motion to true on your client - , but many people do.

> What is the benefit of focusing on the menu’s parent to the user?

The first item was not interacted with nor navigated to, therefore it shouldn't be focused under normal circumstances. It would be unexpected behavior.

Focusing the first item in keyboard interactions is an accessibility hack recommended by W3C:

https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

> Animations enhance experience by drawing attention to state changes and providing intuitive feedback to user actions.

> If you don't find them engaging or useful, that's fine - and you can set prefers-reduced-motion to true on your client - , but many people do.

The question here is not "does an animation have worth", but how is that worth tied to whether an onclick event originated from the mouse or the keyboard? Your reasoning applies equally to both, and thus leaves us still confused: why are we varying the animation by input device?

The question was "Why not just always turn off the animations?"

---

> why are we varying the animation by input device?

Another user explains it here: https://news.ycombinator.com/item?id=42176540

I don't actually agree, I think you can keep the animation and still make the content available immediately for screen readers. (And of course, keyboard navigation is not just for screen reader users!) Maybe someone else knows of some issue I don't.