Skip to content

Cherry pick keyboardcontrols=1 flag to stable12.0#11206

Open
microbit-matt-hillsdon wants to merge 2 commits intomicrosoft:stable12.0from
microbit-matt-hillsdon:keyboardcontrols-flag-stable
Open

Cherry pick keyboardcontrols=1 flag to stable12.0#11206
microbit-matt-hillsdon wants to merge 2 commits intomicrosoft:stable12.0from
microbit-matt-hillsdon:keyboardcontrols-flag-stable

Conversation

@microbit-matt-hillsdon
Copy link
Contributor

@microbit-matt-hillsdon microbit-matt-hillsdon commented Mar 20, 2026

This cherry picks #11185 and the follow-up tidy up #11198 so that we can use the flag in CreateAI against live MakeCode.

In order for me to test this with pxt-microbit stable8.0 I found I needed @riknoll's microsoft/pxt-microbit#6706 (I think it was needed due to a types release on npm) but I think best for you to check and port that if needed.

CC @abchatra.

microbit-matt-hillsdon and others added 2 commits March 20, 2026 12:12
…oft#11185)

* Add keyboardcontrols=1 flag to enable testing "on by default"

This is a temporary flag to enable trialing enabling keyboard controls by
default. Micro:bit Educational Foundation are going to do that in their tools
that embed MakeCode and provide feedback. This might then be a route to simply
enabling them in the next release.

I've implemented this by flipping the default based on the flag.

Now that the user isn't naturally exposed to the help by enabling keyboard
controls, we show the same help toast as Blockly when the workspace is focused
from the skip link. It might be nice to do this in other scenarios (e.g. first
tab to the workspace) but that is a riskier change.

There are still some arguable downsides from this flag that we might want to
address before making it the default:

- It enables "passive focus" dashed outline around blocks. The purpose of this
  is to remind the user of the workspace context (which is where e.g. a toolbox
  block insert will be relative to). But this is more relevant to keyboard
  users. Passive focus is enabled based on Blocky's logic about whether
  keyboard navigation has been used which can be a bit hard to predict as a
  user.

- The active area indicator for the workspace (black focus ring) is also shown
  for all users. When a user clicks on the workspace background we also
  indicate that the workspace itself has focus via the yellow ring (as per
  blocks). We have in the past proposed making this conditional on
  keyboard navigation being in use (so it feels like focus-visible CSS).

Both intentionally unaddressed for now so we can:

1. reduce risk of this change, which is needed in live MakeCode
2. gather feedback specifically from folks who notice these changes

Another aspect we intend to monitor is feedback from folks who might
unintentionally trigger shortcuts.

For telemetry I've intentionally not triggered an event from the default
setting and I've tagged the event source for subsequent changes with the fact
it was on by default.

* keyboardcontrols=1 flag tweaks based on PR feedback:

- use defaultOn as a telemetry dimension
- use BrowserUtils.isMac()

---------

Co-authored-by: Richard Knoll <riknoll@users.noreply.github.com>
…rosoft#11198)

This should have been part of microsoft#11185 to fully address the feedback (I added the
dimension but didn't remove this alternative approach).

Co-authored-by: Richard Knoll <riknoll@users.noreply.github.com>
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.

1 participant