Add keyboardcontrols=1 flag to enable testing "on by default"#11185
Add keyboardcontrols=1 flag to enable testing "on by default"#11185riknoll merged 3 commits intomicrosoft:masterfrom
Conversation
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.
There was a problem hiding this comment.
Pull request overview
This PR introduces a temporary keyboardcontrols=1 URL flag to flip the default for Blocks keyboard controls (accessible blocks), enabling “on by default” trials for embedded MakeCode scenarios and tagging subsequent telemetry sources accordingly. It also adds a one-time help toast when the Blocks workspace is focused via the accessibility “skip link” path to compensate for users no longer seeing enablement guidance.
Changes:
- Added
core.isKeyboardControlsByDefault()to detectkeyboardcontrols=1and use it to default accessible blocks when no persisted preference exists. - Added a pending “keyboard controls help” hint flow that shows a Blockly toast when the workspace is focused after using the accessibility menu’s “Skip to Blocks workspace”.
- Updated user preference defaulting and typings to support flag-based default behavior and telemetry source tagging.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| webapp/src/core.ts | Adds flag detection helper for keyboard controls defaulting. |
| webapp/src/blocks.tsx | Adds pending hint state + help toast shown on workspace focus. |
| webapp/src/auth.ts | Defaults accessible blocks to the flag value when no stored/cloud pref exists. |
| webapp/src/app.tsx | Plumbs optional hint parameter through openBlocks() and tags telemetry sources when flag is active. |
| webapp/src/accessibility.tsx | Triggers the hint behavior when using the accessibility menu to focus the Blocks workspace. |
| pxtlib/auth.ts | Changes default user preferences to avoid proactively setting a fixed accessible-blocks default. |
| localtypings/pxteditor.d.ts | Updates openBlocks() signature to accept an optional hint flag. |
|
|
||
| showKeyboardControlsHint() { | ||
| if (!this.editor || !Blockly.Msg["HELP_PROMPT"]) return; | ||
| const isMac = navigator.platform.startsWith("Mac"); |
There was a problem hiding this comment.
showKeyboardControlsHint() detects macOS via navigator.platform.startsWith("Mac"). The codebase already uses pxt.BrowserUtils.isMac() for this (e.g. webapp/src/components/KeyboardControlsHelp.tsx), and navigator.platform is increasingly unreliable/deprecated across browsers. Using the shared helper will keep platform detection consistent (and avoid iPadOS edge cases).
| const isMac = navigator.platform.startsWith("Mac"); | |
| const isMac = pxt.BrowserUtils.isMac(); |
There was a problem hiding this comment.
|
@abchatra care to weigh in on the telemetry changes? i wonder if it would be better to just add the "on by default" as a custom dimension rather than changing the event name itself |
|
Yes, custom dimension would be good. |
- use defaultOn as a telemetry dimension - use BrowserUtils.isMac()
Makes sense, switched to custom dimension "defaultOn" with true/false values in f9239cb. |
|
So we can test in CreateAI, please can you cherry-pick this to the relevant pxt, bump stable pxt-microbit's version and release to live? Thanks. |
|
Can you test createAI in /beta first and ensure everything works before we port? |
Yes, but I think beta isn't sufficiently up-to-date to do that testing. beta has pxt 12.3.2 which doesn't have this PR yet. If you can tag a pxt release and update beta (or point me to another deployment to test against) then I can test with CreateAI. Thanks. |
|
@microbit-matt-hillsdon I have bumped microbit, please validate when the build is out. |
Thanks @abchatra, I can confirm this is working for us when I test with CreateAI + beta + flag enabled. |
|
@microbit-matt-hillsdon can you port only the required changes to stable12.0 branch and produce a PR? https://github.com/microsoft/pxt/tree/stable12.0 I will take it from there. |
This should have been part of microsoft#11185 to fully address the feedback (I added the dimension but didn't remove this alternative approach).
) This should have been part of #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>
…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>
Thanks, see #11206 |
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:
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. Please consider this part carefully, I don't have enough info to make a good proposal.
Impact on existing users:
Warning: if you test this locally note settings are in .pxt/storage on disk not browser storage.
Fixes microsoft/pxt-microbit#6704