Technical investigation of core menu concept

[wenche]

Acceptance criteria

1. The menu should be accessible to all users including keyboard and screen readers
2. When the menu is open, it should not be possible to tab outside of it (focus lock)
3. When the menu is open, it should not be possible to scroll the underlaying page (?)
4. The menu button for small devices must be accessible and properly linked to the menu state (open/close)
5. The menu should be lightweight in terms of kb
6. The menu should close on router change/navigation
7. The active menu item should be highlighted

Questions

1. Do we need a global state/context for the menu status?
2. Can we avoid to use a Media Query component for loading two different menu components ( ? I hope so, as MQ doesn't work server side... We should at least start out with only CSS MQ? And see how that will affect the markup in terms of loading stuffs that are not actually needed for the current viewport size #504
3. We could probably load some of the helper libraries with next/dynamic?
4. We should move on with the assumption that the menu data is available on server side/build time as it's implemented today, and not as a result of client side fetching (useSwr or similar) because of SEO. How we eventually load the data (issue #497) might affect this

Remaining issues solved by #495 and #496

• Hover/click/hover+click for the opening of the menu -~~ Accordion or navigate to a sub level on mobile~~ -> Accordion
• How do the user navigate to the top level categories

[wenche]

Se Figjam -> Menu

[wenche]

I'm closing this issue now as the list of things we need to remember is pretty much done by the list in this issue, today's discussions and Figjam. No need to invest more time into talking about the technical issues for the menu, let's rather get our hands dirty