Skip to content

Conversation

@kbangelov
Copy link
Contributor

@kbangelov kbangelov commented Dec 19, 2025

Aims to resolve UEPR-445, not before clarifying things.

https://scratchfoundation.atlassian.net/browse/UEPR-445

Proposed Changes

  1. Added tabIndex=0 to the elements in nav bar so they can be focused with tab
  2. Made a context (menu-ref-context) that takes care of tracking which menus and submenus are currently open via their refs. All of the logic with the "isOpen" type of props has been replaced for these menus.
  3. Made a base-menu to be extended by the menus that handles common key pressing, opening, closing logic and more.
  4. Brought out the menu logic in their respective files for the purpose of making them work via base-menu and also for code clarity.

To be discussed additionally

  • I remain uncertain whether the menus should collapse when the innermost items are clicked and which ones. For now they just keep their current behavior.
  • At a couple of places in code when I was making new react elements to replace the long lines of code in menu-bar, I was unsure whether it's a good idea to pass them as a prop or copy-paste the logic directly within the class.
  • The behavior of using screen reader and clicking with cursor leads to improper reads, as opposed to just navigating with keyboard.
  • I made the observation that mode menu seems to act like the other dropdown menus, but it doesn't have an expansion arrow like them. It is not a very active feature of the app, have to make isTotallyNormal=true in gui.jsx to test it.
  • I have also replaced isOpenMenu logic with custom such from the Context. Should I end up removing that entirely from code? I mean I think I have done this entirely in this PR the way it is now but should I? Seems like it will become obsolete.
  • Whatever the comments address.

Tip for reviewing this PR

  • Start from base-menu and menu-ref-context to understand the basic idea behind the code.
  • Test well with a screen reader, since it's likely you'll have one better than my chrome extension.
  • I have a feeling switching language and testing buttons with screen reader doesn't quite work as intended. Have to look into that

Bugs

  • When navigating with screen reader in the edit menu and "Turn on/off Screen Reader" button is triggered, the updated name of that button is not read correctly immediately (old value is read instead as long as we don't focus away - if we come back, then it's read correctly).
  • Bad behavior when combining screen reader usage and clicking with cursor.

Missing

  • aria-selected
  • aria-disabled
  • translations of aria-labels and such
  • The four remaining disabled buttons in the menu bar are untouched. I'm wondering if they're disabled because the changes on them belong to www repo or because they can't be tested locally, in which case I will have to finish them in this PR. Just want to clarify that before touching them.

@kbangelov kbangelov requested a review from a team as a code owner December 19, 2025 14:15
@KManolov3 KManolov3 requested a review from cwillisf December 19, 2025 14:26
@KManolov3 KManolov3 marked this pull request as draft December 19, 2025 14:26
@KManolov3 KManolov3 requested a review from Copilot December 19, 2025 14:27
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR implements keyboard navigation and accessibility improvements for the top navigation bar, enabling users to navigate menu items using Tab and arrow keys. The changes introduce a new context-based system for tracking open menus and managing focus states across nested menu hierarchies.

Key Changes:

  • Added tabIndex attributes and ARIA properties to make menu bar elements keyboard-navigable
  • Implemented arrow key navigation within dropdown menus (Settings, Language, Theme)
  • Created MenuRefContext to manage the state of open menus and focus tracking across the menu hierarchy

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 9 comments.

Show a summary per file
File Description
packages/scratch-gui/src/components/context-menu/menu-path-context.jsx New context provider for tracking open menu references and navigation state
packages/scratch-gui/src/components/menu-bar/settings-menu.jsx Converted to class component with keyboard navigation handlers
packages/scratch-gui/src/components/menu-bar/language-menu.jsx Added keyboard navigation with arrow keys and Enter/Escape handlers
packages/scratch-gui/src/components/menu-bar/theme-menu.jsx Added keyboard navigation similar to language menu
packages/scratch-gui/src/components/menu/menu.jsx Added accessibility props (focusedRef, aria attributes, keyboard handlers)
packages/scratch-gui/src/components/menu-bar/menu-bar.jsx Added tabIndex and ARIA attributes to menu bar items for keyboard access
packages/scratch-gui/src/components/gui/gui.jsx Wrapped MenuBar with MenuRefProvider context
packages/scratch-gui/src/containers/gui.jsx Contains commented test code

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

ref={menuRef}
aria-label={ariaLabel}
aria-selected={isSelected ?? null}
aria-disabled={isDisabled ?? null}
Copy link
Contributor Author

@kbangelov kbangelov Dec 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this applies for both aria-selected and aria-disabled.

They seem to require specific roles for both itself and its container, such as role="option" inside role="listbox", or role="tab" inside role="tablist". For some reason I couldn't really get it to work. But it might be due to my limited screen reader. I'll try to figure out why that is.

@kbangelov kbangelov marked this pull request as ready for review December 29, 2025 13:16
@kbangelov
Copy link
Contributor Author

Ok. Also the tests currently fail. I am not sure I understand why, even with Copilot's help.

@kbangelov
Copy link
Contributor Author

Additionally, the aria-labels don't seem to change after language switch, should be tested with a real screen reader.

]);
}

push (ref, depth) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be very helpful for maintainers if you could add comments explaining the intent of each of the push, pop, cut, etc. functions, since it’s currently not easy to infer.

}

handleKeyPressOpenMenu (e) {
if (e.key === 'ArrowDown') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: Maybe we can extract the keys into an enum?

}

handleMove (direction) {
const newIndex = (this.state.focusedIndex + direction + this.itemRefs.length) % this.itemRefs.length;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: I think a comment here explaining that this line calculates the next focused item index, moving up or down, and wraps around the list so you never go out of bounds would be helpful for future maintainers.

[styles.active]: this.isExpanded()
})}
onClick={this.handleOnOpen}
role="button"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: Does it make sense to use an actual button element? Same question for the other menu components.

}

EditMenu.propTypes = {
intl: intlShape.isRequired,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to use intl from the props you need to call injectIntl to the component, for example:

EditMenuIntl = injectIntl(EditMenu);
export default EditMenuIntl;

Same comment for the other menus where intl is used from the props.

Edit: I just noticed that you're passing it from the MenuBar component. I still think it's better to inject it here rather than passing it from the parent. By the way, if we switch to function components we can use intl from the useIntl hook.

import PropTypes from 'prop-types';
import bindAll from 'lodash.bindall';

export const MenuRefContext = React.createContext(null);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we leave a comment for how this is used, e.g. "Context for manipulating and accessing active menu element. Ensures there is only one open menu stack at a given time. ... "

"integrity": "sha512-NLhDfH/h4O6UOy+0LSso42xvYypClINuMNBVVzX4vX98TmTaTUxwRbXdhucbFMd2qLaCTcLq/PdYrvi8onw90w==",
"dev": true,
"license": "MIT",
"peer": true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd avoid committing these package-lock changes, given that they aren't any package.json changes.

username={username}
accountMenuOptions={accountMenuOptions}
/>}
{!menuBarHidden && <MenuRefProvider>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we only need to manage menu refs on the Menu Bar level? If there are other cases where we'll be managing menu refs outside of here, we'd want to move this to an outer level - otherwise it's fine to stay as-is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose I should have done it here but I do move it in my next task. Although it is illogical in the long term, I think it's fine to stay there in this PR.

import bindAll from 'lodash.bindall';
import PropTypes from 'prop-types';

/* Subclasses must implement (some optionally):
Copy link
Contributor

@KManolov3 KManolov3 Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is hard to maintain (if a method is added or renamed) so I'd prefer not having it. Instead, maybe the base menu-specific logic (as this component contains just logic, without any presentation) can be extracted in a hook and reused in the different menu components.
See https://react.dev/learn/reusing-logic-with-custom-hooks

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also let's ensure the name of this hook is related to the accessibility/tab navigation logic it encapsulates

@@ -0,0 +1,131 @@
import {MenuRefContext} from '../context-menu/menu-ref-context';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General note - after selecting an item in a menu, and the menu closes, we'd want to keep the focus on the top-level menu element (e.g. keep focus on the "Settings" element after selecting a language

}

handleKeyPressOpenMenu (e) {
if (e.key === 'ArrowDown') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine this would depend on whether the menu is horizontal or vertical? I am fine with not adding support for horizontal menus, given we don't have them, but maybe it'd still be useful to add a comment.

onClick={this.props.onRestoreOption(handleRestore)}
menuRef={this.restoreRef}
onParentKeyPress={this.handleKeyPressOpenMenu}
isDisabled={!restorable}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this needed to be added? Because the element was still focusable even if it was disabled? Can we do it either entirely true css styles or through the prop - or do we really need both?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I just wanted to add aria-disabled and aria-expanded for the menus, I did mention I had problems with doing so in a comment of my own, will try to figure it out.

{(this.props.canChangeColorMode || this.props.canChangeLanguage || this.props.canChangeTheme) &&
(<SettingsMenu
menuRef={this.settingsRef}
depth={1}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would there be any way to avoid passing the depth explicitly, but calculating it based on what's in the context when it's opened (and exposing a method from the context to access it)?

openThemeMenu,
closeThemeMenu,
themeMenuOpen
closeThemeMenu
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the XMenuOpen reducers redundant now? If that's the case, is there any reason to continue supporting this file at all?

Copy link
Contributor Author

@kbangelov kbangelov Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they seem to be redundant. I'll remove all the old logic for the ones in the menu bar. We'll eventually delete the file but for now there are still some menus there outside of the scope of the PR

]);
}

push (ref, depth) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about naming these closer to how they're used, rather than toward a data structure namespace - so e.g. open, closeCurrent, closeFrom or something with similar semantics?

>
<MenuSection>
<MenuItem
onClick={onSetMode('NOW')}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're not refering these in several files, let's extract them in an enum

description: 'ARIA label for mode menu'
});

export class ModeMenu extends BaseMenu {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make sure that we don't change any of the previous behaviour here.

this.colorRef = React.createRef();
this.itemRefs = [
...(this.props.canChangeLanguage ? [this.languageRef] : []),
...(this.props.canChangeTheme && this.props.availableThemesLength > 1 ? [this.themeRef] : []),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that the themes menu is not navigable through the keyboard. This is most likely caused by the fact that availableThemesLength is 1 on the initial render, because the membership data has not loaded from the session yet. Since we are only setting the itemRefs in the constructor, the themes menu never becomes a part of the items. This most likely won't be an issue if we switch to a function component, so that's another reason for doing so 😅

@adzhindzhi
Copy link
Contributor

Ok. Also the tests currently fail. I am not sure I understand why, even with Copilot's help.

I think the test failures are because MenuBar is rendered in the tests without the new context provider. With the recent changes, the context ends up being null, so the component can’t render correctly.

@kbangelov kbangelov force-pushed the task/uepr-445-ensure-navigable-toolbar branch from 081c531 to d2fd053 Compare January 8, 2026 14:10
@kbangelov kbangelov force-pushed the task/uepr-445-ensure-navigable-toolbar branch from d63eb5a to d75933d Compare January 9, 2026 08:33
@scratchfoundation scratchfoundation deleted a comment from KManolov3 Jan 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants