Add a spell alpha/numeric option to speak things like ham calls such as ka9nuc correctly as k a 9 n u c.

[mdlawler]

Is your feature request related to a problem? Please describe.

no

Describe the solution you'd like

I's like to see a spell alpha numeric issue that would spell HAM radio calls like ka9nuc as "k a 9 n u c". I believe it should work no matter the case of the letters.

Describe alternatives you've considered

Additional context

This was a useful feature in Window-Eyes.

[davidcarlisle]

For the specific case of 2-letter,digit,3-letter call signs you can do that now with a speech dictionary entry such as

([a-z])([a-z])([0-9])([a-z])([a-z])([a-z])      \1 \2 \3 \4 \5 \6       1       1

that is, regexp replace the call sign by each character separated by a space, with the case insensitive and regex flags set.

[gerald-hartig]

Looks like there is a solution for this. Closing.

[mdlawler]

Gerald are you closing this because you don't believe it is a relevant feature request or because of the regular expression given above? If the former why isn't this a good idea? If the latter do you truly believe that the average blind user, or average nonblind user for that matter, should be expected to create a speech dictionary with a regular expression to accomplish this? There are many blind hams that I know would appreciate such a feature. I believe that a screen reader should do as much as possible to make it as easy as possible for the user to use.

[sclower]

End users should not be expected to manually edit speech dictionaries to achieve this functionality. While it may be technically possible, that alone does not make it an optimal or user-friendly solution—nor does it eliminate the underlying need for a more accessible, built-in approach.

[davidcarlisle]

In case it isn't clear, I posted the regex above but I'm just an interested passer-by here: I have no involvement with nvda, and just made the comment as an observation which I thought may help someone wanting this immediately whether or not the feature gets added later.

[Adriani90]

I am reopening due to pending discussion and alternative proposals.

[mdlawler]

Sean I'm asking the following questions to understand Nvaccess thinking not to be confrontational. Why would you close this as not planned and not just leave it open or put it at the lowest priority? A screen reader's job is to present information to the user in the most efficient and convenient way. There are a lot of blind hams that would appreciate the feature. Other screen readers have the feature. I'm guessing that if I said that I'd write the feature and do a pull request that you'd say that it wouldn't be accepted. Isn't the goal of open source to allow others to contribute worthwhile ideas and improvements. You might not mean for this to happen, but Nvaccess comes off as kind of like a private club that wants to do things its way and says it wants input and help, but only if that conforms to a narrow idea of what Nvaccess considers correct. I've heard this from several former Window-Eyes users and it is one of the things that motivated me to try to get involved and further the project. Doug Geoffray, from Microsoft, has told me that he has discussed my involvement with Mick, but honestly the reception I've gotten from this issue tracker with the idea to quickly close most of my feature requests by Adriani90 and then your reactions sends the message of thanks, but no thanks. I'm sorry if this comes off as offensive as I really don't mean to do so. I really want to help and contribute and I have a lot of experience to bring to the table, but if I'm going to meet resistance at every turn then honestly I've got better things to do with my time.

[SaschaCowley]

@mdlawler can you explain exactly how this feature would work? I.e. what is the user experience of this proposed feature? Why do the existing options (speech dictionaries, the many options for spelling text, an add-on) not meet this user need? And how does this proposal fit into our product vision, in particular point 16?

[mdlawler]

I would say that items 2 and 14 are as relevant as 16 from your product vision for this feature. As far as how the feature would work it would be much simpler than having the user have to create a regular expression in a dictionary. It would just be another option under speech that if checked would send "k a 9 n u c" instead of "ka9nuc" to the synthesizer. Basically it would look at words separated by white space and if the word contained both alpha and numeric characters then it would insert spaces between the characters before sending them to speech. This would happen automatically if the check box was checked not requiring the user to manually find the item and manually spell it. Ham radio operators frequently use calls, they even refer to each other by the ham call rather than the actual name of the person. Ham radio software also uses ham calls a lot. It would do nothing for braille since it doesn't matter for presentation on a braille display. It could possibly be done as an add-on, but I personally feel that it is a fine line with add-ons especially if I'm offering to do the feature I'm not interested in only doing an add-on because I think something like this is more useful and discoverable if it is in core. Add-ons have to be searched for by users meaning that less users will know about the feature. This feature is small and self contained so it's not like I'm proposing a large amount of code to core to implement it.

[josephsl]

Hi,

Interesting. However, have you considered non-English speech and spelling, especially languages where word boundaries are not clear or a single character can be considered a word? Sure, we can advise speakers of those languages to uncheck the proposed phonetic pronunciation feature (in order to do that effectively, we need to enumerate these languages), but then we run into another question on speech engine support.

I think the idea on adding this directly into core sounds reasonable (as it will deal with speech processing). However, please do consider an add-on route (what makes add-ons discoverable are promotions and well-written description, documentation, and word of mouth). The discovery issue was a huge problem prior to the opening of the add-on store; discovery is still a problem but the add-on store has some of the most prominent add-ons registered there.

Thanks.

[SaschaCowley]

@mdlawler in calling out item 16, I was not discounting the rest of the product vision, I was suggesting that I think it is the real barrier to what you're proposing. Item 16 states that, in deciding whether something should be included in core, we consider whether the feature will:

• provide utility to a significant proportion of users in day-to-day use.

You have called out a group of users who are likely a minority of our users.

• are a necessity for a small subset of our users, without which NVDA would not be functional for them.

NVDA is clearly still usable for ham radio operators. While perhaps not maximally efficient, there are workarounds for the deficiency you have identified.