Keyboard support fix on mobile menu

[digitoimistodude]

Keyboard support fix on mobile menu

[ronilaukkarinen]

Thanks for this. We'll look into it in some point. If you have ideas about resolving it, pull requests are welcome.

[ronilaukkarinen]

We've been looking into this in many versions during this one year period when improving accessibility. The nav works better now but if there are multi-level dropdowns under the last link there is just no practical way to figure out the real last visible link programmately based on one's actions.

In the latest Air there's an update that forces the last dropdown to expand by default so we have even mid-way "solution" to this. However it will not solve the issue that keyboard would keep the tabbing inside nav if user decides to collapse the last dropdown menu during tabbing prev and next inside the mobile menu.

I have not figured out a way to "record" the change in subdown toggle so that the last link variable would change with the toggling. This has been tricky to solve so pull requests are still more than welcome.

[michaelbourne]

Quick thought here: why not change the focus trap to check if Node.contains is false for the nav parent (meaning the next tab item is outside of the nav list), and then set the focus to the button? In my head, this should solve all the issues.

Just checked the latest release and the solution to open the last dropdown doesnt work well when the last dropdown isnt the last element, and it's no longer responsive (focus trap only works when the window is loaded under 960px, dropdown stays opened if window is resized larger.)

[ronilaukkarinen]

@michaelbourne A very good point! I'm bummed how we haven't thought outside the box and tried that approach here. We are currently in progress to rewrite parts of the navigation.js as it contains some duplicates and messy code (also when implemented latest eslint last time we noticed bunch of problems, hehe, been doing stuff with blindfold for too long I guess).

That bug about resizing in between of responsive breakpoint back and forth has been there since the first version as we don't have any resize events in place. I think it's not that important since people don't constantly resize the window.

Our first focus is to get navigation.js to go through linters during upcoming days. After this we start to solve other problems with the navigation.js. If you have already a suggestion how to implement the better focus trap, feel free to send a PR!

[michaelbourne]

The resizing bug is just more noticeable now with the forced dropdown and window width check for the focus trap :)

Totally understood though. You've been committing like crazy this last month! When you get the new navigation.js file pushed, I'll go through it and see if I can get it working better for everyone. I have a few ideas that sound great in my head, but might not translate to code haha.

Appreciate the continued efforts!

[ronilaukkarinen]

The resizing bug is just more noticeable now with the forced dropdown and window width check for the focus trap :)

True.

Yeah, Air-light is our gem and affects in our everyday working lives so we try our best to make it as good as possible :) Glad you're helping, always feels good to get outside input.

[ronilaukkarinen]

This is so rare scenario and there has been no solutions or activity so I'm moving forward and closing this issue...