feat: add EsMobileNav

[ericdouglaspratt]

🔗 Linked issue

• https://energysage.atlassian.net/browse/CEO-545

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

• Added EsMobileNav, along with subcomponents EsMobileNavContent, EsMobileNavCustomItem, EsMobileNavLink, EsMobileNavTrigger, and EsMobileSubNav
• Added a new site navigation example that brings together EsMobileNav with EsStickyBar
• Added EsLogo with built-in alt text support (and control), since EsMobileNav will automatically come with it and because our license in this repo already covers it
• Added IconChargingStation
• Fixed an issue with EsStickyBar where class prop wasn't placed on the right element
• Changed the stickyBar layout to a minimal layout and used it on both the sticky bar and site navigation docs pages
• Accessibility: The entire menu can be traversed by keyboard and will hide and show the sublevels as appropriate depending on where your focus is. For example, if you use keyboard to tab to a middle menu item, open its submenu, tab through a few items, then hit shift-tab until you give focus to the item previous to the one that opened this submenu, the submenu will close and show a focus outline around that item, at the upper level. This is unavoidable the way Reka UI's NavigationMenu works, but is exactly the same as what you'd tab through in a desktop menu with openable submenus. In submenus where there is a custom item, it does seem to focus trap you when tabbing forward.
• Subtle design cues:
  • When clicking a menu item to open a submenu, that menu item will highlight to give the user feedback. When going back up one level, during the animation, that same menu item will briefly be highlighted to show you where you came from, and then will de-highlight so you can peruse the menu normally.
  • When navigating up and down submenu levels, not only does the menu header persist and the title change, but the titles subtly fade and animate in the same direction that you're going to help reinforce where everything's coming from, where it's going, and where you are in the tree.
• Accepted minor flaws:
  • It proved too difficult to get the custom footer to stick to the bottom and be always visible, so it just scrolls with the rest of the menu content
  • It proved too difficult to prevent momentum scrolling of the menu from briefly revealing the page content beneath on the top or bottom

First, second, and third level examples

Desktop behavior

🥼 Testing

• Tested locally at http://localhost:8500/molecules/mobile-nav and http://localhost:8500/examples/site-navigation
• Tested with VoiceOver and keyboard navigation
• Tested in Chrome, Edge, Firefox, and Safari

🧐 Feedback Requested / Focus Areas

• Overall

📝 Checklist

• I have verified accessibility of any new components by:
  • automated check with the WAVE browser extension
  • navigating by keyboard
  • using with a screen reader (e.g. VoiceOver on Safari)
• I have updated any applicable documentation.

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[nathanielwarner]

👀

[nathanielwarner]

Nice work on this! There's an incredible amount of intricate logic that I've done my best to understand. It looks visually excellent as well, and adheres to the design.

Accessibiilty is definitely a huge improvement over the current nav! I made one specific inline recommendation, and I have a couple of other notes:

• Keyboard navigation is not working properly within the sub-menus. You can navigate into them, but you cannot get out of it using the keyboard. If we're not able to fix this, we should warn on the docs page that this is only for mobile navigation and it does not meet accessibility criteria for desktop use.
• It seems like VoiceOver would work for blind users, other than the minor issue with the logo resolved by removing the aria-labelledby. There is however some strange behavior where it's possible to get the screen reader's focus out of sync with the visual presentation. When you select "home solar" using the screen reader, the screen reader is still on the expand/collapse button even though it visually looks like it's on the first item within the sub-menu "getting started". If you then click this button again, things really fall apart and the whole menu goes white. It'd be good to fix this if we can, because it's likely to create a confusing experience for those who are visually impaired, and are able to hear things that don't correspond to what they're seeing.

[ericdouglaspratt]

@nathanielwarner

Keyboard navigation is not working properly within the sub-menus. You can navigate into them, but you cannot get out of it using the keyboard. If we're not able to fix this, we should warn on the docs page that this is only for mobile navigation and it does not meet accessibility criteria for desktop use.

Very true. For some reason it wasn't focus trapping me consistently before in submenus, but now it is. I've fixed this by adding hidden back and close buttons to each submenu, and keeping them accessible to visual users by showing a focus outline on the actual back and close buttons in the nav content header when those hidden buttons receive focus.

I also discovered a pretty serious VoiceOver bug where when you went back to a parent menu, VoiceOver would lose focus and bump you back out to the top of the page (same for when you closed the menu itself). I've fixed this by explicitly giving focus to the menu trigger button just before closing the menu, so focus position is retained.

It seems like VoiceOver would work for blind users, other than the minor issue with the logo resolved by removing the aria-labelledby. There is however some strange behavior where it's possible to get the screen reader's focus out of sync with the visual presentation. When you select "home solar" using the screen reader, the screen reader is still on the expand/collapse button even though it visually looks like it's on the first item within the sub-menu "getting started". If you then click this button again, things really fall apart and the whole menu goes white. It'd be good to fix this if we can, because it's likely to create a confusing experience for those who are visually impaired, and are able to hear things that don't correspond to what they're seeing.

Very good catch! This was a gap in my own logic, nothing to do with Reka UI - fixed in b8492be

[nathanielwarner]

This a fascinating set of workarounds. Fairly ugly but it seems to work pretty well. I do still see a couple of quirks:

• Within a sub-menu, navigating backwards with shift-tab will go over two invisible buttons before it gets to the ones with visible outline. One of those invisible buttons seems to do nothing, while the other seems to be another back button. Navigating forwards somehow doesn't trigger this condition.
• When navigating into a sub-menu with VoiceOver, the indicator shows the screen reader as being where it was (on the screen) prior to the click, which makes it look like it's over one of the elements on the new sub-menu. But the voice prompt (and actual behavior) show that the screen reader is still on the expand/collapse button which was just clicked. "Clicking" it again with the screen reader will get you back to the parent menu, and now with the latest round of fixes, the menu keeps up visually as well. The only issue here is the visual mismatch; the screen reader is initially pointing to an element which is no longer in the field of view.

This implementation is working well enough, and the two things mentioned above are fairly minor edge cases in my opinion, more like "nice to fix if easy".