BUG: Keyboard-tab order upon navigate (bug?)

[klohman]

**Issue moved from Trello UX Pain points

Describe the Bug
From Kelsey: I was exploring the new Practioner search function on localhost/docker + Firefox this evening. I'm logged in as clerkofcourt currently and noticed that tabbing through the page for mouse-free navigation completely skips the "Messages" and "Document QC" and "Trial Sessions" and "Advanced" topbar menu navigation. It does hit "Reports" and the search bar though.

navigation in Safari when logged in as docketclerk is a little strange too. Tabbing only moves between the URL bar and search bar, and skips over a lot of what can be navigated on the page

To Reproduce
Steps to reproduce the behavior:

1. Log in as clerk of court
2. Tab through application navigation

Expected Behavior
on load tab should start at url then hit skip nav then to main nav.

Actual Behavior
tabbing through the page for mouse-free navigation completely skips the "Messages" and "Document QC" and "Trial Sessions" and "Advanced" in firefox for topbar menu navigation
Safari (docket clerk)- Tabbing only moves between the URL bar and search bar, and skips over a lot of what can be navigated on the page

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Cause of Bug, If Known

Process for Logging a Bug:

• Complete the above information
• Add a severity tag (Critical, High Severity, Medium Severity or Low Severity). See below for priority definition.

Severity Definition:

• Critical Defect
  Blocks entire system's or module’s functionality
  No workarounds available
  Testing cannot proceed further without bug being fixed.

• High-severity Defect
  Affects key functionality of an application
  There's a workaround, but not obvious or easy
  App behaves in a way that is strongly different from the one stated in the requirements

• Medium-severity Defect
  A minor function does not behave in a way stated in the requirements.
  Workaround is available and easy

• Low-severity Defect
  Mostly related to an application’s UI
  Doesn't need a workaround, because it doesn't impact functionality

Definition of Done (Updated 4-14-21)

Product Owner

• Bug fix has been validated in the Court's test environment

Engineering

• Automated test scripts have been written
• Field level and page level validation errors (front-end and server-side) integrated and functioning
• Verify that language for docket record for internal users and external users is identical
• New screens have been added to pa11y scripts
• All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html
• READMEs, other appropriate docs, JSDocs and swagger/APIs fully updated
• UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required)
• Interactors should validate entities before calling persistence methods
• Code refactored for clarity and to remove any known technical debt
• Deployed to the Court's test environment

[klohman]

Notes from Trello card from @kkoskelin

Here's an exceptional article from Accessibility industry expert, Marcy Sutton :
https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/

Discussion on complexities of managing focus for purposes of accessibility when given a single-page application can be found here: https://adhocteam.us/2018/02/20/developer-driven-focus-management-for-single-page-applications/

I'd like to learn more about: what version of Safari, and on which operating system. I cannot replicate the issue mentioned in Safari.

[rachaelparris]

Is this actionable yet? Is this even a bug? We need more information - possibly a spike on single-page app accessibility. Possibly an opportunity for a micro request with 18F accessibility resources.

[JessicaMarine]

@adunkman This bug got logged back when Kelsey was doing code review. However, it's not clear what the issue is or how to resolve it. Would you be able to investigate and provide more information?

[mariahkannenberg]

Blocked - 18F (Andrew) Looking into this one

[adunkman]

Regardless of the browser, the issue here is with tab order — here’s a demo (be sure to unmute):

not-hitting-skip-link.mov

It appears to be happening because tabindex is set to 0 on the skip to main content link, and -1 on the page heading. This issue represents this behavior as a bug — that focus should start at the skip to main content link when loading the page.

(Safari in this issue is a red herring and can be ignored — Safari’s tabbing model is different without VoiceOver being enabled).

Let me know if you have any further questions, I’d be happy to help!

[kkoskelin]

ustaxcourt#1376

[kkoskelin]

Some side-chatter from the TTS Slack suggests that we've been on the correct path this entire time. Here are several articles which advocate doing essentially what we've already implemented -- that of focusing a page header upon route-change.

https://www.upyoura11y.com/handling-focus/

https://simplyaccessible.com/article/spangular-accessibility/#acc-heading-3

https://angular.io/guide/accessibility#routing-and-focus-management

Special thanks to notes from Robert Jolly at 18F for his accessibility expertise and knowledge sharing.

cc: @adunkman you'll be happy to see we've got things where they need to be!