Multiple accessibility problems with mobile menu

[iamjolly]

Expected Behavior

People using screen readers on mobile devices, keyboards with mobile devices, or keyboards and browser zoom with mobile view enabled should be able to open, access, and close the mobile menu with the same relative ease of anyone else using the site.

Actual Behavior

1. Menu button lacks descriptive state (e.g. aria-expanded="false"), therefore a blind or low vision user does not know that the menu button is closed and can open the nav menu.
2. When the menu button is pressed/activated, focus is not shifted to the modal-like menu, therefore there is no indication that anything occurred. Additionally, the nav items are in a div near the bottom/end of the page's source, so a user must navigate to the bottom of the page to get to the menu.
3. The modal for the menu has a close button, but it is unlabeled. The svg needs an aria-label or there should be visually-hidden text within the button to provide assistive technology users with an accessible name. Currently, VoiceOver on iOS with Safari guesses it is a close button, but other assistive technology/OS/browser combinations may not offer this feature.

Steps to reproduce the behavior

• Open 18F site using a mobile device and using a screen reader/assistive technology, follow the next set of steps
• Navigate to and activate the main menu button
• Navigate to the nav menu items
• Navigate to the close button

This issue is done when:

• Menu button accurately announces its state (collapsed/expanded)
• Focus is programmatically set (via JS) to the menu when opened
• Close button has an accessible name and is announced by assistive technologies
• Trap focus within the nav drawer when it is open
• Focus is returned to the menu button when mobile menu is closed
• BONUS: Menu is closed and focus returned to button when user presses esc button on their keyboard.

Please unzip and watch this
screen recording of iPhone using Safari and VoiceOver to demonstrate the problem.

Additional resources that may be helpful:

• Launchy - an accessible modal demo and code by Scott Vinkle
• Menus& Menu Buttons - Inclusive Components by Heydon Pickering

[Dahianna]

Thanks Robert! We'll added to our current accessibility work

[iamjolly]

Thanks @Dahianna - Unless you all feel strongly we should wait, I may work with @aduth on a PR to address this quickly since it is a significant barrier to folks.

[Dahianna]

Not at all. Feel free to work with to Abdul to get it fixed

[aduth]

@iamjolly and I had spent some of the morning today looking at how best to approach this issue. It's especially relevant in mind of the ongoing work at #3097 to upgrade to USWDS v2, since part of the issue here is that the current 18F website doesn't take advantage of the built-in accessibility of USWDS navigation components and instead implements its own mobile menu behaviors.

Thus, we considered a few ways to approach this:

1. Build upon the current implementation as a more immediate solution to resolve the issues
   • Branch: 3188-a11y-mobile-nav
   • Live preview
   • Pros:
     • There are only a few changes necessary
     • Design consistency with the current website
   • Cons:
     • It's essentially a reimplementation of what's already provided through USWDS. Some of this is more difficult than others to implement (focus trap, for example).
     • As a reimplementation, there's no guarantee the behavior remains in sync with USWDS. For example, the current branch will set focus on the container of the mobile menu drawer, rather than the first focused item. On the other hand, if this approach is ideal, it could be valuable to consider as a proposal for upstream improvement to USWDS.
2. Convert the current navigation to use USWDS v1 already available today on the website
   • Branch: update/nav-uswds
   • Live preview
   • Pros:
     • Reuses behaviors already available through USWDS
     • Consistent behavior and appearance with USWDS
     • It could benefit USWDS v2 update #3097 in that it moves closer to USWDS conventions
   • Cons:
     • Conflicts with 18F custom header styling. It could be considered a "good thing" in how it embraces USWDS conventions, but it does diverge slightly from the current site design.
     • It could make work in USWDS v2 update #3097 more difficult, since the changes are likely conflicting and will need updates to the updated class names of USWDS v2
3. Await the completion of the USWDS v2 upgrade in USWDS v2 update #3097
   • Pros:
     • Already needed and in progress
     • Takes advantage of latest, consistent accessibility behaviors of USWDS navigation components
   • Cons:
     • This issue will continue to affect people until the changes from USWDS v2 update #3097 are landed, and it's unclear if it's expected to be complete in the near future

I'd be curious to hear if you have any thoughts about this. I see that there have been quite a few recent updates to #3097, which could have an impact on which of these options could be best to consider.

[Dahianna]

@iamjolly and @aduth are you available to join us during our co-working session next week? We can discuss these options. I'll add you to the invite.

[aduth]

That sounds good @Dahianna . Talk to you then!