@lindapaiste Initially, I attempted to add an event listener in the useEffect inside NavDropdownMenu.jsx, but it doesn't seem to be doing the trick. I noticed we already have useKeyDownHandlers utility in the codebase. Do you think it could be leveraged for this use case?

@mohitbalwani I think this not a bug but intentional
@raclim @lindapaiste what do you think about this?

@mohitbalwani I also think it's intentional as we can move backward using Shift+Tab

It's not a "bug" but it's a good feature request! Right now everything is navigable using the Tab key but I have wanted to support using arrow keys as a secondary method. There's a //TODO comment somewhere in the code about it. I think in one of the Drowdown components.

@mohitbalwani yes you should be able to make use of useKeyDownHandlers here.

We want the arrows to do nothing if the component is not focused. When a dropdown is expanded, you would be able to use the up and down arrows to move up or down the list of items. I'm not sure what's supposed to happen if you're on the last item of the list and then press the down arrow. Should it loop back around to the start? Close the dropdown? It would be good if we can find some relevant ARIA guidelines so we know how to handle every case.

First things first, let's make sure that our HTML markup is as descriptive as possible. We want the browser to understand what these elements represent and how to interact with them. We might not need to use a lot of explicit event handling. I'm not sure if this section is describing behavior that's automatic? https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menu_role#keyboard_interactions

We want the menubar role on the main nav bar, menu on each dropdown, menuitem on each item, etc.

This should be the first course of action, before adding any event handlers.

I would like to work on this issue my initial action will be starting with (Nav.jsx) p5.js-web-editor/client/modules/IDE/components/Header/Nav.jsx

And then changing the usage of ul and li tag with menu and menu item ,
I want to raise a PR on this issue what’s your opinion about this @lindapaiste , @mohitbalwani

@Prateek-Fst I started working on the ARIA markup in a draft PR #2968 but I didn’t finish. You can fork that branch and address the “pending” items listed in that PR.

We want the arrows to do nothing if the component is not focused. When a dropdown is expanded, you would be able to use the up and down arrows to move up or down the list of items. I'm not sure what's supposed to happen if you're on the last item of the list and then press the down arrow. Should it loop back around to the start? Close the dropdown? It would be good if we can find some relevant ARIA guidelines so we know how to handle every case.

according to the recent ARIA authoring guide, wrapping from the last to first or vice versa is optional depending on the use case. I think that since it's a fairly small set of options in the dropdown menus, wrapping can make sense here. As far as I've learned, menus should only be closed via keyboard if focus is moved to a different item in the menubar or an option within a menu is activated (and if the esc key is pressed, of course).

I just finished adding ARIA markup a few days ago so I'm giving this issue some attention now, though if anyone else has already started working on it please chime in!

@tes

menus should only be closed via keyboard if focus is moved to a different item in the menubar or an option within a menu is activated (and if the esc key is pressed, of course).

have you had a chance to work on this more? esc is not working for me on desktop windows 10 brave/chromium... it's frustrating :D

Probably important to note though, when I press escape the menu stays open and appears to lose focus, so the only way I can make it go away is to click somewhere else in code then put the cursor back where I was to continue typing. i.e. menu stays and keyboard input gets lost.

have you had a chance to work on this more? esc is not working for me on desktop windows 10 brave/chromium... it's frustrating :D

Probably important to note though, when I press escape the menu stays open and appears to lose focus, so the only way I can make it go away is to click somewhere else in code then put the cursor back where I was to continue typing. i.e. menu stays and keyboard input gets lost.

hi @IshinoAkuma , i just finished refactoring the component and am finalizing keyboard behaviors in #3320. thanks for noting the windows behavior, that looks very inconvenient and definitely not accessible! i'm hoping to be ready with the PR some time next week and will test the behaviors across devices.