@jcsteh I'm trying to debug an issue where "space" in focus mode after an image in a content editable. The speech ends up as "graphic blah space" in both firefox and chrome. A space character in the textWithFields while in getTextInfoSpeech is converted to the word "space" which originates here.

I don't understand why the space is included, is there anything you can remember about this? Even test cases or something this supports that might help me avoiding a regression while fixing this?

The word "space" comes from spelling the character called from:

If I recall correctly, the reason for the space is this:

For contentEditable, graphics, etc. essentially act like characters. That is, they occupy one stop with right/left arrow. However, they have no text, so we need some character as a placeholder. A space is generally what we use in this case. You can also see this in virtual buffers. For example:

data:text/html,before<hr>after

If you repeatedly move through that with the right arrow key, you'll eventually hear "separator space". That's not ideal - it should probably just say "separator" - but we need some character in the stream.

One way to fix this that I vaguely recall considering is to use some other character (e.g. U+FFFC or U+FFFD) and explicitly "silence" that in speech and braille.

I'm considering whether it makes sense in this block (in speech/init.py) to yield the spelling sequence after yield speechSequence. The conditions above this are really specific to moving by one character, so if there is content in the initialFields then we don't need the space?

If I understand correctly, the problem with this is that it would prevent reading of spaces, say, at the start of links. For example:

data:text/html,before<pre><a href="https://nvaccess.org/"> test</a>

Right arrow to the link. You should hear "link space"; the space is real and the user should know about it. If you make this change, you might only hear "link".

Here's a more realistic example of where we don't want to lose the space:

data:text/html,<pre>This is my<ins> lovely</ins> dog.</pre>

When you right arrow to the insertion, you should hear "insertion space". It's really important in this case that the user knows the space is part of the insertion.

Great! Thanks for the example!

Turns out either removing this space or changing it to something else (eg to "testing") does not seem to have any impact on those examples, but does fix the bug I'm seeing with:

data:text/html,<div contenteditable="true"><span>First</span><span><img src="https://picsum.photos/200" alt="an alt"></span><span>last</span></div>

This image has the alt text "an alt", apologies that this is more confusing than I intended.

Steps to repro:

• In focus mode
• From the start of the line use right arrow to move through the word "first" then hear "graphic an alt space"

I tested removing the space, which in particular causes issues for routing in braille. I also tested using the object replacement character (0xFFFC), which then gets displayed in braille. Although we use the object replacement character in a few places in NVDA, generally I think it's a mistake when we know what it is acting as a stand in for. Instead it would be preferable to use type like TextInfos.ControlField to represent it and handle it's replacement at the presentation layer (braille or speech). I'm actually not sure why ControlFields don't already handle this. Also, object replacement characters could come from the content itself. Using them as a stand in can cause:

• inability to differentiate internal obj replacement chars from external.
• inability to provide different presentations for internal obj replacement chars based on what they stand in for.

I think I'm going to have to leave this behavior as it is. I'll create a new issue, and add some comments to the code.

Ideally we would replace this space with an NVDA internal object replacement representation object, or customize ControlField to handle this. everywhere that we process field commands.

See issue ""space" announced after image" #11291