Improve menu navigation for screen readers

[sherson]

We received this feedback:

The app is for the most part accessible. I am able to access the roots and stops, and add stops to my favorites list.

A big accessibility bug is lack of information when a user opens the menu at the top of the app. Voiceover focus stays on the Menu button, and there is no indication that a menu has been opened, unless a user taps on the middle of the screen and then cursor focus jumps into the menu.

The text spoken by Voiceover should read something like "Menu collapsed", and then "Menu open, double tap to close" when a user interacts with it. This will make navigating the app a much more straightforward process. I'd be happy to sit with your programmers and go over this.

[mboneil10]

The back button doesn't indicate that the page has been changed, either. Is this something to consider?

[mboneil10]

Researching my above question and more. It might take some time to figure out an answer. Since it hasn't become an issue, I'm more inclined to leave it as is.

FWIW, I've noticed prominent styles of back buttons on my phone apps. The back button is an arrow < or>. Typical approaches:

1. Text for the hierarchy is present next to the arrow. The text provides the destination for the back button. When the back button is used, VoiceOver states the new page title. example: "Search back button" is said by VoiceOver on < Search. VoiceOver says "Search" because the current page has changed.

2. Text for the hierarchy is not present next to the arrow. VoiceOver refers to the arrow as a generic back button. When one navigates using the button, the page title is given by VoiceOver. example: "Back button" is said by VoiceOver for <. VoiceOver says "Search" because the current page has changed.

That being said, our app does neither.

[sherson]

Let's put back button behavior/style on the list of things to ask our tester.

[mboneil10]

My original fix was going to be an aria-label on menuToggle that changes depending on it being opened or closed. It would look like: <... aria-label="{{open ? 'menu opened' : 'menu closed'}}" ... > with some boolean value open. So, this would mean that when the menu opens, the screenreader would read "menu opened" and "menu closed" when the menu closes. However, I couldn't determine the value of open without going into the typescript (meh). I tried using ionOpen in the label, but that change produced a blank page. If the label above just worked or there was something as simple as replacing open with something else, then that would be great.

After talking to @werebus, we noticed this fix is not the answer. My screenreader doesn't say if the menu is opened or closed, and there's not an obvious close menu button (the user could try to swipe the menu or click away from the menu to close). Closing the menu is unclear with and without a screenreader, so this means I need to change labels and redesign the menu. @werebus suggested a close button in the top right corner of the menu page. I might use Ionic's menuClose button for the close button. In fact, Ionic's docs use a menuClose button in the examples of menuToggle. They're paired together in all the examples I've found in the MenuToggle page, the Menu page, and the Menu Close page. I'll need to play with focus on the page, but it'll happen.

Now, for those of you who aren't curious about my current plan and reasons for it... TL;DR:

• Add close button to the menu. Try menuClose, if that doesn't work, add a generic close button.
• Update aria-label on menuToggle button to "open the menu" (or something similar to that).
• Create aria-label on close button of "close the menu".
• Adjust focus for the screenreader accordingly.