fix keyboard navigation order to be shown while pressing the tab keys

[AllanOXDi]

Summary

This PR fixes the hidden focus of navigating when using the tab key.
closes #3786

Screenshots (if applicable)

Kolibri.Studio.-.7.December.2022.mp4

Reviewer guidance

How can a reviewer test these changes?

1. Step 1 - Navigate the menu using the tab key

Are there any risky areas that deserve extra testing?

References

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[LianaHarris360]

@AllanOXDi Thank you for making the focus more noticeable when navigating with the tab key. The other issue is that while using the keyboard navigation, the focus still jumps to the items in the closed side menu, but the user can't see that those items are being focused on.

This image shows the tab order and items 7-13 are hidden but are still being placed into focus when navigating with the tab key. These are the items in the side navigation drawer that is currently closed.

If possible, I think a solution could be to set the tabindex on these items to 0 only when the drawer is open. And if the drawer is closed, the tabindex could be -1 to make the items unreachable through the keyboard navigation.

[AllanOXDi]

How did I miss that? Thanks for the pointer.

[AllanOXDi]

Hi @LianaHarris360, While working on the issue again and also putting into consideration of the desired behaviour. I thought of a different desired behaviour instead. My thought is that we should not skip the drawer while navigating with the tab key when it's closed. In this case, the drawer on both sides should be open while it is on focus. Why am I saying so? I imagine that by the time a user is using the tab key to navigate through the page. The user is either unable to use the mouse or is using a screen reader. So when we implement the current desired behaviour, we will be making the page inaccessible to some users. I am tagging @radinamatic, @rtibbles and @marcellamaki to weigh in on their thoughts.

[LianaHarris360]

@AllanOXDi To clarify, are you suggesting that, for example, when navigating with the tab key, the left side drawer will automatically open once it gets to item 7? And when it is no longer focusing on the items in the drawer (so moving to item 14 in the picture), it should automatically close?

[AllanOXDi]

Yes! That's my thought.

[radinamatic]

@AllanOXDi The same way mouse users would click on the user menu button to open the options in the "drawer" IF THEY NEED TO, keyboard users (both sighted and while using the screenreader) would navigate to the user menu button with the Tab key, and then press Enter key to open the options in the "drawer", again, ONLY IF THEY NEED TO.

As @LianaHarris360 mentioned, the options inside the "drawer" need to be inserted in the Tab order (that is, be reachable by the Tab key) ONLY once the keyboard user has opened the menu ("drawer") by pressing the Enter key. If the keyboard user does not need any of the options inside the user menu ("drawer"), they will not open it and continue navigating the rest of the page with the Tab key.

[AllanOXDi]

Thanks for clarifying @radinamatic

[radinamatic]

Opening the user menu ("drawer") automatically when the button is focused is not necessary, as the button should have the aria-label saying Open user menu or something to that effect. If the user needs to open it they will, otherwise they'll continue navigating their merry way 🙂

[AllanOXDi]

Hi @LianaHarris360, I hope this is mimicking the intended behaviour.

screen-capture.3.mp4

[LianaHarris360]

Hi @AllanOXDi Yep, that is the desired behavior! The only other thing I noticed was that your local branch needs to be synced with the remote unstable branch. Before creating a new feature branch, I like to pull in the latest changes of the branch I want to merge my changes into. Great work on this pr!