Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to independently choose whether or not to speak Enter key #6553

Open
rimas-kudelis opened this issue Nov 11, 2016 · 30 comments
Open

Allow to independently choose whether or not to speak Enter key #6553

rimas-kudelis opened this issue Nov 11, 2016 · 30 comments

Comments

@rimas-kudelis
Copy link

@rimas-kudelis rimas-kudelis commented Nov 11, 2016

Enter is currently treated as a command key. That means if you want Enter to be spoken, you have to enable speaking ALL of the command keys.

Since Enter is obviously also used when entering text, as opposed to just triggering commands, I think it would make sense to allow choosing whether or not to speak it separately.

Alternatively, instead of creating a separate checkbox, it might make more sense to actually speak one (or both) of the newline characters when they are entered. Currently, it seems they (or more precisely, only the LF character) are only spoken when navigating through a textfield with arrow keys, but not when they are entered from keyboard.

Issue 4029 is also somewhat related to this one, but they aren't interdependent or anything like that.

@feerrenrut
Copy link
Member

@feerrenrut feerrenrut commented Nov 14, 2016

@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 #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.

@rimas-kudelis
Copy link
Author

@rimas-kudelis rimas-kudelis commented Nov 14, 2016

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.

@derekriemer
Copy link
Collaborator

@derekriemer derekriemer commented Nov 14, 2016

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.

@leonardder
Copy link
Collaborator

@leonardder leonardder commented Nov 14, 2016

I'd like this and vote for option 2

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Nov 14, 2016

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Nov 14, 2016

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...

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Nov 14, 2016

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Nov 14, 2016

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?

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Nov 14, 2016

@rimas-kudelis
Copy link
Author

@rimas-kudelis rimas-kudelis commented Nov 14, 2016

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

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Nov 14, 2016

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...

@bhavyashah
Copy link

@bhavyashah bhavyashah commented Nov 14, 2016

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.

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Nov 14, 2016

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.

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Nov 15, 2016

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...

@derekriemer
Copy link
Collaborator

@derekriemer derekriemer commented Nov 15, 2016

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.

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Nov 15, 2016

@rimas-kudelis
Copy link
Author

@rimas-kudelis rimas-kudelis commented Nov 15, 2016

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?

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Nov 15, 2016

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...

@nsousa2007
Copy link

@nsousa2007 nsousa2007 commented Mar 2, 2017

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

@bhavyashah
Copy link

@bhavyashah bhavyashah commented Mar 2, 2017

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Mar 3, 2017

@rimas-kudelis
Copy link
Author

@rimas-kudelis rimas-kudelis commented Mar 3, 2017

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.

@Qchristensen
Copy link
Member

@Qchristensen Qchristensen commented Nov 19, 2018

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

@Qchristensen
Copy link
Member

@Qchristensen Qchristensen commented Jul 15, 2020

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.

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Jul 16, 2020

@Qchristensen
Copy link
Member

@Qchristensen Qchristensen commented Jul 23, 2020

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)

@Qchristensen
Copy link
Member

@Qchristensen Qchristensen commented Jul 23, 2020

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)
  1. 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?

  2. 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?

@ruifontes
Copy link
Contributor

@ruifontes ruifontes commented Jul 23, 2020

@XLTechie
Copy link
Contributor

@XLTechie XLTechie commented Jul 23, 2020

@Qchristensen
Copy link
Member

@Qchristensen Qchristensen commented Jul 23, 2020

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.

@feerrenrut feerrenrut added the ux label Jul 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants