@rimas-kudelis Thanks for raising this issue.

P3 considering this is a fairly specific use, however I think this could improve the user experience for some people.

So conceptually there seems to be at least the following approaches:

• Add a way to control / set the "level" that control characters are spoken. This could be done in one of the following ways perhaps:
  1. Add categories for control characters eg "all", "some", "none". We would have to work out which characters fell into which category. To satisfy this issue and Add a option to read punctuations when inputting them. #4029, enter would need to be in "some" and space not in "some" (only in "all")
  2. Create a dictionary of the control characters so they can be turned on or off independently.
• Consider enter a regular character rather than a control character. And speak it if "speak typed characters" is enabled.

I think considering Enter a regular character would be a more practical approach, and probably much easier to implement. One thing to keep in mind though is that instead of speaking "carriage return line feed" that key press should speak "enter", because breaking a line is not what this key always does.

As to adding categories for control characters – I think this would be overkill. I can hardly imagine people needing that, although I might be wrong.

Having a UI for speaking certain command keys would be really nice. It's
currently all or none, and some people might want to hear anything with
tab, but not control, or similar.

I'd like this and vote for option 2

Hello!

At least in Portugal and Brasil many people want to hear Control, Alt,
Function keys, Tab and Enter, but not arrow keys...

It will be very nice to be able to define which keys are echoed...

Basically, most users want to hear all keys pressed except arrow keys...
I suppose it is more an audible confirmation of pressing the right key...

It is possible to, at least, diferenciate between command keys and arrows?

I guess one could say that the arrow key block is shaped rather distinctively, thus making audible confirmation unnecessary.

The three major reasons are:
In a desktop keyboard the arrows are easy to locate...
Having the command keys announced helps beginner users to be sure they have
pressed the right combination...
Hearing left arrow, , right arrow, up arrow or down arrow before every
letter or list item is totally unproductive...

Hi,
Also, all standard navigation commands involving the arrow keys, such
as Ctrl, Alt and Shift (selection) keys when pressed in conjunction
with the arrow keys would be unjustifiably and and unnecessarily
verbose to verbalize, and thus should be omitted in the category
intermediate between all keys and no keys. The arrows are part of
every other key command a screen reader user would press, since they
essentially power up basic navigation in Windows, and thus, would be
counter-productive and annoyingly repetitive in most cases, thus, in
my opinion, justifying the omission of the arrow keys in this
intermediate mode being conceptualized as well.
Thanks.

I still don't really follow the reasoning here; surely hearing "f1",
"control+o", "NVDA+f12", etc. is just as unproductive. That said, it does
seem the user demand, for whatever reason, is high here. I don't think this
justifies making every key configurable, though. However, it might justify
a separate option for reporting of the arrow keys.

That said, #5484 (the original issue regarding the arrow keys) actually
contradicts this issue. It suggests that enter should be spoken as a
command key, but that, say, NVDA+b shouldn't be. This emphasises my point
that this decision is entirely arbitrary. At least the current behaviour is
consistent: all keys that aren't typed characters are command keys.

If we had a list of keys to choose from and key combinations like NVDA+b
need to be listed, that list would contain 1000 or more entries. This is
why the list idea is totally infeasible.

A compromise solution:
1 - Considere Enter, and accents like accut accent, grave accent, tilde and
carete, as a character;
2 - Separate arrows from command keys.

That way will have three group of keys;
1 - Typeable characters including Enter and accents;
2 - Arrow keys;
3 - All other keys;

Other solution is mapping all command keys, after all they are only a few
more than 40, since the association are already announced when you enable
the announcement of command keys...

What about 3 levels of keys similar to punctuation? Yeah, I know it's
going to cause the same thing we have with punctuation though.

I guess another compromise is to split command keys into groups, such as Alt+foo, Ctrl+foo, NVDA+foo, Arrow keys etc., and allowing to toggle these groups. How many of them would there be?

Too many!
1 - Alt+letters;
2 - Control+letters;
3 - Control+Alt+letters;
4 - Alt+Shift+letters;
5 - Control+Shift+letters;
6 - Control+Alt+Shift+letters;
7 - Control+Function keys(Fx);
8 - Alt+Fx;
9 - Alt+Control+Fx;
and so on, and so on...

Hi,

I aggree with Rui Fontes Solution:
"A compromise solution:
1 - Considere Enter, and accents like accut accent, grave accent, tilde and
carete, as a character;
2 - Separate arrows from command keys.
That way will have three group of keys;
1 - Typeable characters including Enter and accents;
2 - Arrow keys;
3 - All other keys;"

Most of my students become confused, when Enter key and accents are not spoken.
Please work on this solution as soon as possible. I know most of us don't need it, but we cannot forget there are beginers who need it!
Thanks

I guess I'm going to back Rui's suggestion as well, let's have three types of command keys:
1 - Typeable characters including Enter and accents;
2 - Arrow keys;
3 - All other command keys.
(And yeah, I just pasted this from a comment above).

As to why somebody might want arrow keys as a separate group, I suppose the example of navigating a menu is really good: if I remember correctly, when navigating menu using access keys (such as f, o, n), you automatically trigger a command if that key only has one command attached to it in the current submenu. Whereas when using arrow keys, each menu item is being navigated to, but not triggered, so hearing stuff like "File [press a key] Down Arrow Open [press a key] Down Arrow New" might be annoying and rather counter-productive, since you don't really care which key you've just pressed as long as you know the menu item that is currently navigated to.

As this comes up regularly, has there been any movement on this issue recently?

Just had another request for this, and on the arrow keys point, they mentioned that they initially put speak command keys on, but then turned it off again primarily because of the arrow keys being announced - and they discovered they press arrow keys a lot more than they would have initially thought.

People may use speak command keys for a variety of reasons. With the increasing popularity of laptops with all manner of key configurations, I think the assumption that the arrow keys are easy to find is less and less guaranteed.

I'm going to add two comments. In this one I will sum up the thread so far, and in the next, I will add my proposed solution to move forward.

So, firstly, to sum up, the main points and suggestions from the thread so far:
1 - Having only ENTER spoken (in the same way as space is as a character) would be desirable for some users.
2 - There is a linked issue #4029 requesting that reporting of "space" be made optional.
3 - Having several states for NVDA+4 not just on or off ("all", "some", "none" suggested)
4 - Create a dictionary of every command key so they can be toggled individually. This would be quite complex and potentially off-putting for the less advanced users it may most benefit.
5 - Arrow keys are easy to find on many keyboards and speaking them adds a lot of verbosity.
6 - Remove speaking of arrows at all.
7 - Speaking navigation keys (arrows but also eg control+arrows or shift+navigation keys to select) is also too verbose.
8 - Treat accents like accut accent, grave accent, tilde, carete, cedilla,
trema, diaresis as a character.
9 - Allow independently toggling key groups such as Alt+foo, Ctrl+foo, NVDA+foo, Arrow keys etc. (This would also include alt+control+foo, shift+control+foo, shift+alt+foo, etc)

Having read through the whole thread and summed it up in the previous comment, I'd like to propose the following three solutions to move this issue forward:

1. Give "Speak typed characters" a third option. So:

• "None" (as "off" currently)
• "Characters" (as "on" currently)
• "All" ("Characters", plus ENTER and TAB because when typing, in places such as Word, both add whitespace, and having them in speak command keys would enable them to be set as needed in configuration profiles)

2. I'm not familiar with the issue of how accut accent, grave accent, tilde, carete, cedilla, trema, diaresis are currently spoken. I agree that it sounds like they should be in speak typed characters from the conversation. Rui could you please maybe move that to a separate issue if still needed?

3. Make "Speak command keys" also have three options:

• "None" (as "off" currently)
• "Complex" (speak everything except navigation keys)
• "All" (as "Complex" but add navigation keys: arrows, home, end, page up, page down, shift+navigation keys, control+navigation keys, control+shift+navigation keys etc).

Yes it's arbitrary, but as noted, just about any solution is, and this solution at least gives a fair amount of flexibility with minimal complexity. Once implemented, we could then create a new issue if people really do want to distinguish between say function keys and other command keys or something.

If we're agreed on that, I'd like to propose considering moving forward on implementing it. Alternatively if 1 and / or 2 are palatable, then we can move them to their own issues and we can continue discussing the best way to move forward on command keys themselves here?

Rui,

I wasn't arguing against implementing 2 (diacritics and accents etc being added to speak typed characters), merely that I wasn't familiar with why they weren't already and whether there was some separate issue involved, hence moving discussion on that to its own issue.

@XLTechie Yes this issue was initially around speaking the enter key in speak command keys, but reading through all the conversation, I felt it made more sense, and made it more flexible to take the opportunity to enhance BOTH speak typed characters and speak command keys.

Re when to speak space, the linked issue (#4029) aside (which can perhaps best be discussed in that issue rather than adding more complexity to this one), I felt for the sake of continuity for existing users, at this point, I would leave it where it is, spoken currently as other characters are when that option is enabled.

Re the middle option - sure I'm happy to go with "some" rather than "complex". I was simply trying to convey what got spoken but you are right, it doesn't really do that and "some" is consistent with other 3-option toggles.