@nvdaes, I have not tested this PR myself.

I acknowledge the need to have spelling errors reported in brailles, especially, but not only, for deaf blind users.
Though I am concerned by the UX provided in this PR. Having "Font attribute" setting controlling reporting spelling errors in braille makes Document formatting reporting confusing, more than today, I'd say.

Until now:

• font attribute controlled reporting of font properties such as bold, italic, underlined and strikethrough, vocally in the past and then also in braille with Separate font attribute reporting between speech and braille #16748.
• spelling errors controlled reporting spelling errors, by speech

These 2 items were not linked. Now, the UX proposed in this PR links them, making the definition of a font attribute much less clear, and actually inexact.

And what if I want to have spelling errors reported in braille but not by speech?

IMO, to be able to customise how additional text information is reported in braille (font attributes, spelling mistakes, we need a specific dedicated panel for Braille formatting reporting.

@nvdaes I agree with @CyrilleB79 that this should not be controlled by the "font attributes" option. I suggest that we change the "spelling errors" option to allow the user to select speech and/or braille as can be done with font attributes. This will require changing the way NVDA calculates the indicators in braille. I think the approach I would take would be to add a callable to FormattingMarker that returns True if the marker should be used if appropriate, and False if not. We can then refactor the code to use that callable rather than the overarching check as done currently. What do you think?

@SaschaCowley and @CyrilleB79 , I see what Cyrille means and I agree with you, Sascha. I like your idea and I'll try to implement it.
@josephsl , m is delimited by unicode patterns like other attributes.

Why did you use "m" letter while we have "Spelling errors" in the UI, and not "Mistakes"? Have you considered using "e" instead?
It's worth noting that "s" cannot be used since it is already used by "strikethrough"

Why did you use "m" letter while we have "Spelling errors" in the UI, and not "Mistakes"? Have you considered using "e" instead? It's worth noting that "s" cannot be used since it is already used by "strikethrough"

Yes, in fact I have considered using "e". I'll change this and will continue my work when your PR to add ability to use audio is merged.
I think we can use a single line in the changelog mentioning our names and the corresponding issues, something like:

• Added ability to report spelling errors with audio and braille (@CyrilleB79, @nvdaes)

@SaschaCowley you wrote:

@nvdaes I agree with @CyrilleB79 that this should not be controlled by the "font attributes" option. I suggest that we change the "spelling errors" option to allow the user to select speech and/or braille as can be done with font attributes.

What do you suggest regarding the GUI and taking into account the work in #17997 (see more specifically #17997 (comment))?

@nvdaes you wrote:

I think we can use a single line in the changelog mentioning our names and the corresponding issues, something like:

* Added ability to report spelling errors with audio and braille (@CyrilleB79, @nvdaes)

Feel free to do so when the final design is clearer and if you still find it appropriate.

@CyrilleB79 thanks for bringing that to my attention. I'm not sure of a good solution at present. I'll talk to the team about it.

@CyrilleB79 @nvdaes We think that a check list with "speech", "sound" and "braille" options is most appropriate in this case. These could be internally stored as a bit flag.

Sascha wrote:

We think that a check list with "speech", "sound" and "braille" options is most appropriate in this case. These could be internally stored as a bit flag.

I agree with this proposal. I'll continue my work, as mentioned, when Cyrille's work about sound and speech is merged.

How would you modify the toggle script?

Cyrille wrote:

How would you modify the toggle script?

Probably I would remove it, but I would study other similar cases to decide the best way to proceed.

@CyrilleB79 we could remove it, make the script cycle between all options, or add new scripts to toggle braille and speech/sound

@nvdaes #17997 has just been merged. You can now continue with this PR if you wish.

Regarding the toggle script, I suggest:

• keep the existing script and adapt it to cycle through all possible audio feedback.
• if you wish/find it useful, add a toggle script, still unassigned, to have spelling mistake reported in braille or not.

@CyrilleB79 , though I like a lot your proposed script, unfortunately, for now I'm getting critical errors. I'll test in more detail.

@CyrilleB79 , perhaps your script failed due to something wrong in my local system. But I've realised about this after modifying my previous script, since it failed too and I have run scons source again. Then the script worked
I think that now the script is clearer than my original one, and both, yours and mine are valid.
I will test again since, the first time that I've tested, it seemed not to work properly, but perhaps I didn't test well since after that all seems to work as expected.

Thanks a lot @SaschaCowley ! I love these simplifications in the code. I'll test this later just to be asbolutely sure, and I'll provide feedback here.

@SaschaCowley , thanks for your suggestions. I think that this is ready for review.