fix: improve screenreader output for workspace comments by maribethb · Pull Request #9351 · RaspberryPiFoundation/blockly

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb · 2025-09-08T23:43:36Z

The basics

I validated my changes

The details

Resolves

Fixes#9314
Addresses the workspace comment part of #9311

Proposed Changes

When a workspace comment is selected the output is:

[The text of the comment], Comment, button, group (24 of 9)

(tbh I don't understand the group part)

When you press enter to go into editing mode the output is:

Edit text [The text of the comment], insertion at end of text

When you focus the collapse icon:

Collapse comment, button

Focus the delete icon:

Remove comment, button

(the context menu uses the word remove, not delete, and i used the same message for that)

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

Reason for Changes

The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

Test Coverage

Documentation

Additional Information

~~Note that after #9350 is submitted I will need to run npm run messages and commit the results. This shouldn't be merged before then.~~ Done

BenHenning

Thanks @maribethb! I think this makes sense--just had a couple of comments.

BenHenning · 2025-09-09T18:58:45Z

Note that previously these had labels set to things like DoNotOveride? and I don't know what that means. I have to assume that was something Ben set for testing or the initial version of this, I'm not sure.

I set some 'DoNotOverride?' (perhaps misspelled) to help discover some of the less obvious labels, though I missed a few in the initial batch of work and am happy to see them get fixed properly.

Reason for Changes
The most controversial thing here, I think, is that I'm calling the entire comment a button. I think it's basically true since you press enter to edit it. I think we talked about saying fields with editors are buttons too, for that reason. But I'm not sure where landed with that. I think we should do the same thing here that we do for fields with editors.

We did indeed discuss this for fields and other things that are "clickable." Button is probably the closest role paradigm to most of these types of interactive elements in Blockly, though we may use roledescription to be more specific that the item isn't actually a button but can be interacted like a button.

maribethb · 2025-09-17T19:35:54Z

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

BenHenning

Double checked the accessibility tree and it looks correct, there are no extraneous elements that aren't focusable listed under the workspace comment element. It's still announced as group but there doesn't seem to be a good way to convince VO not to say that since there is in fact a group of elements nested inside it. So I think this is as good as I know how to get it.

(& your reply to the button thread)

This is probably the best we're going to get for now, and it seems reasonable for testing. I wouldn't be surprised if we need to iterate on it more, but I do worry about overfocusing on one particular screen reader since there seems like a lot of potential variance between them.

…der-issues ## The basics - [x] I [validated my changes](https://developers.google.com/blockly/guides/contribute/core#making_and_verifying_a_change) ## The details ### Resolves Fixes#9301Fixes#9312Fixes#9313 Fixes part of #9304 ### Proposed Changes This introduces a variety of specific changes to resolve several issues for screen reader work, including introducing fundamental support for field labeling. Specifically: - Field labels have been simplified to only use their custom defined ARIA name otherwise they are null (and thus should be ignored for readout purposes) which wraps up the remaining high-level work for #9301 (#9450 tracks more specific follow-up work to improve upon what's been established at this point). The PR also introduces an ARIA override for number inputs in math blocks so that the readout is correct for them. - Bubble labeling is more explicit now which is useful for mutators (#9312), warnings, and comments. The general improvement for bubbles wraps up the remaining work for #9313 as well since the core issue was resolved in #9351. By default a bubble has no ARIA label. - #9304 is partly being addressed here with the change to field images: they are no longer being added to the accessibility node tree unless they are actually navigable (that is, clickable). Part of #9304's goal is to remove extraneous nodes. - Finally, a typo was fixed for 'replaceable blocks' since these were not reading out correctly. This was noticed in passing and isn't directly related to the other issues. ### Reason for Changes This PR is largely being used as a basis for one particularly significant issue: #9301. Field labeling has undergone several iterations over the past few months and the team seems comfortable sticking with a "do as little as possible" approach when determining the label, thus justifying the need for expecting more specific customization (i.e. #9450). To this end it's important to be clear that getting fields to a good state is not actually "done" but the need to track it as a large incomplete thing has ended. Note that one important part of #9301 was updating field plugins to be accessible--this largely seems unnecessary as-is as it will be completely dependent on the needs of future user tests. The long-term plan will need to account for making all fields in `blockly-samples` accessible (per #9307). Some of the terminology used here (e.g. for bubbles) will likely need to change after user testing, but it's important to establish that _something_ correct is communicated even if the terminology may require scaffolding and/or refinement. It's important to note that while non-clickable field images are no longer in the node graph, their ARIA presence still exists as part of the fluent block labeling solution. That is, `FieldImage`'s alt text is used as part of constructing a fluent block label (sometimes to confusing effect--see #9452). ### Test Coverage No tests needed since these are experimental changes and do not change existing test behaviors. ### Documentation No documentation changes are needed for these experimental changes. ### Additional Information None.

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

maribethb requested a review from a team as a code owner September 8, 2025 23:43

maribethb requested review from BenHenning and removed request for a teamSeptember 8, 2025 23:43

github-actionsBot assigned BenHenning Sep 8, 2025

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 8, 2025

maribethb force-pushed the ws-comments branch from 32691f8 to e13bcedCompare September 9, 2025 16:42

github-actionsBot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 9, 2025

BenHenning reviewed Sep 9, 2025
View reviewed changes

Comment threadmsg/json/qqq.json Outdated
Comment threadcore/comments/comment_view.ts Outdated

maribethb added 4 commits September 16, 2025 16:28

fix: improve screenreader output for workspace comments
d6c05db

fix: run npm run messages to fully add new message
2d7564e

fix: remove useless bubble label
d9ee818

fix: use roledescription instead of description
776f199

maribethb force-pushed the ws-comments branch from e13bced to 776f199Compare September 16, 2025 23:44

BenHenning approved these changes Sep 18, 2025
View reviewed changes

maribethb merged commit 27fe764 into RaspberryPiFoundation:add-screen-reader-support-experimentalSep 18, 2025
9 checks passed

This was referenced Oct 28, 2025
Discussion of the application of roles such as listbox, checkbox, and textbox #9313
Closed
fix: Miscellaneous screen reader issues (experimental) #9446
Merged

maribethb deleted the ws-comments branch July 7, 2026 20:53

Uh oh!

Conversation

maribethb commented Sep 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The basics

The details

Resolves

Proposed Changes

Reason for Changes

Test Coverage

Documentation

Additional Information

Uh oh!

BenHenning left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

BenHenning commented Sep 9, 2025

Reason for Changes

Uh oh!

maribethb commented Sep 17, 2025

Uh oh!

BenHenning left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

maribethb commented Sep 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The basics

The details

Resolves

Proposed Changes

Reason for Changes

Test Coverage

Documentation

Additional Information

Uh oh!

BenHenning left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

BenHenning commented Sep 9, 2025

Reason for Changes

Uh oh!

maribethb commented Sep 17, 2025

Uh oh!

BenHenning left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

maribethb commented Sep 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The basics

The details

Resolves

Proposed Changes

Reason for Changes

Test Coverage

maribethb commented Sep 8, 2025•
edited
Loading

maribethb commented Sep 8, 2025•
edited
Loading

maribethb commented Sep 8, 2025•
edited
Loading

maribethb commented Sep 8, 2025•
edited
Loading