You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
add "begin stack" label and other relevant things to full-block field labels #9864
I have searched for similar issues before opening a new one.
Description
blocks that are full-block field blocks get special cased in block aria composer, the special case should include adding things like "begin stack", "disabled", the custom input name, etc if they are relevant to the block
changed the title [-]add "begin stack" label and other relevant things to top-level full-block field labels[/-][+]add "begin stack" label and other relevant things to full-block field labels[/+]on May 22, 2026
Wanted to flag that we're hoping we'll get this one in a follow-up release, in particular to get the custom input names.
We also spotted that we have two similar types of full field blocks that are treated differently:
Case 1
[dropdown, label] currently explains that it's a dropdown, the label is read at all. It reads as per the field and I guess it's an example of something this bug might address. Example:
Case 2
The other order, [label, dropdown], is read as "label, dropdown-value, value", but with no clue that it's actually a dropdown you can interact with.
Example (only nyan is in the dropdown field):
"melody, nyan, value"
This is because BlockSvg.getFullBlockField only considers the first field.
Ideally we'd have getFullBlockField return the full block field either way (this gets us the first readout in both cases) and also have the other text (melody/beat) included.
Another case we're hoping this will help us with. Currently the shadow blocks in the conditions of MakeCode's "if" are just read as the fields and so don't have context as to which branch you're in. This works OK when you drop in a non-shadow condition. We'd love to test any improvements in this area (e.g. we can test a PR in the MakeCode context).
This is because BlockSvg.getFullBlockField only considers the first field.
blocks that have "full block fields" should only have one field. I don't think either of the two blocks in your first comment should actually be full block fields?
Case 1
[dropdown, label] currently explains that it's a dropdown, the label is read at all. It reads as per the field and I guess it's an example of something this bug might address.
I am having trouble parsing what you mean, could you clarify current vs expected output here?
Case 2
The other order, [label, dropdown], is read as "label, dropdown-value, value", but with no clue that it's actually a dropdown you can interact with. "melody, nyan, value"
That's because this isn't a full block field, if i'm understanding correctly. this is a regular value block, you need to navigate into the block to interact with the dropdown. this would be just like any other block where we don't announce the field type when we're reading the block content. do you have a link to a beta i could play with?
Beta is https://makecode.microbit.org/beta. Having said that, Rob and I think your position is reasonable and we should probably park those blocks to revisit another time.
Another case we're hoping this will help us with. Currently the shadow blocks in the conditions of MakeCode's "if" are just read as the fields and so don't have context as to which branch you're in. This works OK when you drop in a non-shadow condition. We'd love to test any improvements in this area (e.g. we can test a PR in the MakeCode context).
This is directly relevant to the issue. (TIL that "logic_boolean" blocks are only full-block fields when they are shadow blocks.)
I have opened a PR that should improve this:
Activity
[-]add "begin stack" label and other relevant things to top-level full-block field labels[/-][+]add "begin stack" label and other relevant things to full-block field labels[/+]microbit-matt-hillsdon commentedon Jun 16, 2026
Wanted to flag that we're hoping we'll get this one in a follow-up release, in particular to get the custom input names.
We also spotted that we have two similar types of full field blocks that are treated differently:
Case 1
[dropdown, label] currently explains that it's a dropdown, the label is read at all. It reads as per the field and I guess it's an example of something this bug might address. Example:
Case 2
The other order, [label, dropdown], is read as "label, dropdown-value, value", but with no clue that it's actually a dropdown you can interact with.
Example (only nyan is in the dropdown field):

"melody, nyan, value"
This is because
BlockSvg.getFullBlockFieldonly considers the first field.Ideally we'd have getFullBlockField return the full block field either way (this gets us the first readout in both cases) and also have the other text (melody/beat) included.
microbit-matt-hillsdon commentedon Jun 16, 2026
Another case we're hoping this will help us with. Currently the shadow blocks in the conditions of MakeCode's "if" are just read as the fields and so don't have context as to which branch you're in. This works OK when you drop in a non-shadow condition. We'd love to test any improvements in this area (e.g. we can test a PR in the MakeCode context).
maribethb commentedon Jun 16, 2026
blocks that have "full block fields" should only have one field. I don't think either of the two blocks in your first comment should actually be full block fields?
I am having trouble parsing what you mean, could you clarify current vs expected output here?
maribethb commentedon Jun 16, 2026
That's because this isn't a full block field, if i'm understanding correctly. this is a regular value block, you need to navigate into the block to interact with the dropdown. this would be just like any other block where we don't announce the field type when we're reading the block content. do you have a link to a beta i could play with?
microbit-matt-hillsdon commentedon Jun 18, 2026
Beta is https://makecode.microbit.org/beta. Having said that, Rob and I think your position is reasonable and we should probably park those blocks to revisit another time.
mikeharv commentedon Jun 22, 2026
This is directly relevant to the issue. (TIL that
"logic_boolean"blocks are only full-block fields when they are shadow blocks.)I have opened a PR that should improve this: