Speak punctuation that is alone in a string

[shoogle]

Problem

If a string consists of just symbols or punctuation characters (like comma "," or exclamation mark "!") then NVDA says nothing, so a blind user will have no idea what is there.

Solution

By default, NVDA should speak symbols and punctuation characters when they are alone, but not when they form part of a sentence like "Hello, World!" (unless a high verbosity setting is enabled).

[shoogle]

As an example of where this would be useful, MuseScore is a sheet music application written in C++ and Qt. Due to the complex nature of sheet music, we implement our own accessibility in the score, including for actions like text editing and text selection. We do this by sending a status message to NVDA that consists of the character to the right of the cursor. If that character is a symbol then we would like NVDA to say something rather than nothing. We are currently forced to maintain a list of punctuation characters and their names, but our list is incomplete so we think it would be better for the screen reader to do the conversion.

Of course this is arguably MuseScore's fault for trying to do accessibility itself rather than using standard widgets. We're working to address this, but it will take time as decisions were made for historic reasons and these are difficult for us to change now.

If you want to try text editing in MuseScore, please try the beta release for version 3.5. Select a note or rest in the score and press Ctrl+T to add staff text, or double click on some existing text like the score title.

[XLTechie]

For what it's worth, I would agree that this would be useful.

As someone who does a lot of editing, knowing about rogue punctuation would be quite handy.

[DrSooom]

@shoogle: Would it help to add all Unicode names of the Unicode block "Musical Symbols" (U+1D100 to U+1D1FF) to NVDA's symbols.dic files? Then they are spoken correctly independently of the used TTS. I know that ♯, ♭ and ♮ were used in MuseScore 2.x, but no longer in the 3.x versions. In the meantime these three Unicode characters are displayed as #, b and = in the German 8-dob braille table (see: liblouis/liblouis#685) due to my suggestion.

Note: BrailleExtender 20.05.28 and higher are able to display the Unicode name of a Unicode character, if it's available in the symbols.dic files, in braille on a braille display, but this would require much more space than HUC8, which is normally shown for undefined characters (in liblouis braille tables) since that BrailleExtender version.

[shoogle]

@DrSooom, it's a good suggestion, but perhaps not as helpul as it might appear at first glance, at least not for MuseScore. Most of MuseScore's symbols are not actually in Unicode; they are in SMuFL. In any case, MuseScore already has names (and translations) available for every musical symbol that it is capable of displaying. These names are used in the UI for things like tooltips, status bar text, and indexing to enable users to search for symbols by name. It is very little effort for us to expose these names to the screen reader.

In some cases symbols can have more than one name, so for consistency's sake it's better for us to use our name rather than a generic Unicode name. Also, the Unicode names tend to be prefixed by "music" or "musical symbol" (e.g. ♯ is "music sharp sign") , which is helpful to non-musicians, but musicians don't need the prefix (we would just call it "sharp"). In the few cases that MuseScore does use Unicode symbols (usually in written text rather than in the score) we handle them specifically.

So as a sheet music program, we don't mind dealing with the musical symbols ourselves, but we would like NVDA to deal with all the non-musical symbols for us. Of course you are very welcome to take care of musical symbols for the sake of non-musicians, or for musicians using non-music software, but MuseScore would continue to handle such symbols internally as it does now.

[DrSooom]

@shoogle: Thanks a lot for this information. And yes, at the moment NVDA (2019.2.1 (last Python 2 version) and 2020.1) sadly only allows to define one single name for a Unicode character – and not two on two different symbol levels. That's something I have to put into a separate issue in the near future, because I'm not satisfied with the current situation. Depending on the situation a short and a long Unicode name are required, as you already pointed out correctly.

Then this issue here is a duplicate of issue #10164. See especially my comment here.

[DrSooom]

See also: Issue #9138 and #11486 and PR #9154

[Adriani90]

cc: @JulienCochuyt