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

Question mark is not verbalized #10164

Open
minorninth opened this issue Sep 3, 2019 · 12 comments
Open

Question mark is not verbalized #10164

minorninth opened this issue Sep 3, 2019 · 12 comments

Comments

@minorninth
Copy link

###Steps to reproduce:

Create a website with the following text as a placeholder, e.g.:

Actual behavior:

NVDA says nothing for the question mark

Expected behavior:

NVDA should say the word question mark.

Of course this depends on verbosity but it'd be nice if the heuristics could handle this sort of case. A single punctuation character in the middle of a sentence surrounded by whitespace, or surrounded by single/double quotes, is a good sign that it ought to be described verbosely.

Using Chrome 76, NVDA 2019.2, Win 10, default espeak voice, default verbosity settings

@Brian1Gaff
Copy link

Brian1Gaff commented Sep 3, 2019 via email

@JulienCochuyt
Copy link
Collaborator

JulienCochuyt commented Sep 5, 2019

I am in favor of adapting the verbosity as you describe in some situations, but beware that NVDA does not only speak English.

A single punctuation character in the middle of a sentence surrounded by whitespace

Actually, in French by example, many punctuation marks (including the question mark) are separated from the surrounding words with whitespace.
Eg. : (en) "How are you?" / (fr) « Comment allez-vous ? »

or surrounded by single/double quotes

I would assume this is right.
Can someone please confirm or come up with an example where this is wrong?
Note that French and German (and probably a few other languages) also use additional quotes that might be worth considering.

Furthermore, I guess any single printable character should be announced when found in the following situations:

  • in a web browser, in a block node (like a div, not a span)
  • in any kind of text entry, when announcing the selection with NVDA+shift+s
  • in a multi-line text entry, when found alone on a line (in many reading situations such as caret movement / reporting the current line / review by line / say all)
  • when announcing the content of the clipboard with NVDA+c
  • when reporting the status bar with NVDA+shift+end
  • when reporting the foreground object with NVDA+b

@DrSooom
Copy link

DrSooom commented Sep 6, 2019

« Parlez-vous français ? »
« Oui, mais il est très mal. »

« and » are used in German (Germany/Austria) books and as far as I know also in other documents in Switzerland. In Germany and Austria „ and “ are normally used as quotation marks (excluding books as mentioned before). Furthermore the order of « and » are also differently used between French documents and German books.

In which situation Unicode characters should be spoken or not are highly different between the used languages and the used TTS synthesizers. Therefore everything, which @JulienCochuyt suggested, must be changeable by the user. Perhaps also in combination with using configuration profiles. Then it would make sense. Otherwise the end user will get crazy within a few hours if something was "suddenly" changed by the devs. See also: Issue #5235 and #6039

@JulienCochuyt
Copy link
Collaborator

„ and “

These could be handled unambiguously if not used differently in other languages.

the order of « and » are also differently used between French documents and German books.

Thank you for the precision, I forgot that. Makes handling of these glyphs language-dependent, which is less likely to be implemented soon.

Therefore everything, which @JulienCochuyt suggested, must be changeable by the user.

While you are fully right on the quote marks side, all of the six items in my dotted list refer to situations in which a printable character is found isolated. I really think these should be spoken unconditionally and unconfigurably.
I'd be sincerely interested if you could please come up with an example of a situation in which this change would not be adequate.

@DrSooom
Copy link

DrSooom commented Sep 6, 2019

', ›, ‚, ‘ and ’ as well as ", „, “, ”, « and » are all used in German.

Personally I don't want that the characters in a status bar or that one, which are reported from the clipboard, are differently pronounced as they are normally spoken. In Notepad++ ":" and "|" are surrounded by spaces, but this isn't the case with the slash ("/") in the status bar in the VLC media player. And in Microsoft Word 2010 " and ' are used in the status bar tooltips and in the ribbon menu respectively in their tooltips. So this is the perfect example how differently quotation marks and half quotation marks are used just in German (Austria).

Therefore I'm not a friend of such generalizations. There are too many different situations, to many applications, too many different – and sadly often not typically correct designed – documents, e-books and websites and too many personally user's preferences, that it's absolutely not possible to find the one solution which fits everybody's wishes exactly the same.

@JulienCochuyt
Copy link
Collaborator

@DrSooom, I think you are missing my point here. All apologies if I haven't been clear enough.
I do not advocate that characters found in a status bar or in the clipboard should be announced in a special different manner.
I think a single printable character, found on its own in the listed situations should be.
The fact that the character is single, on its own, alone, with nothing else around makes IMHO a huge difference.
That is, by example, whatever the verbosity settings, if an application title bar contains nothing else than a question mark, NVDA+t should always announce the question mark and never stay silent.
The same applies eg. in a multiline text field when the caret is moved by line: If a line contains one single printable character, it should IMHO be announced as if the caret was moved by character.
This is just my generalization of the example given by the poster of this issue, complaining (wisely IMHO), that a placeholder might currently sound empty while it is not.

Is this rewording clearer? Do you agree with this rephrased proposal?

@DrSooom
Copy link

DrSooom commented Sep 7, 2019

@JulienCochuyt: Okay, thanks for the clarification. And yes, I agree that there should be an option to enable speaking all Unicode characters on character level if all of them within a container are allocated to the same Unicode code point. A container could be the title bar, the status bar, a folder/file name, a line in a document, a link on a website or also the content of a cell within a table.

Example for a text file:

ABCDE
-----
FGHIJ

is spoken as:

  • Disabled: A B C D E (nothing) F G H I J
  • Enabled: A B C D E Five dash(es)/minus F G H I J

But we also have to handle the behavior for tabs (U+0009), spaces (U+0020) and non-breaking spaces (U+00A0). There are also a few more spaces in the Unicode block General Punctuation.

@Adriani90
Copy link
Collaborator

Actually I agree with @JulienCochuyt here. We do not need an option to enable this announcement. This should work by default. In any case, if there is only one character and I navigate with arrow keys character by character, I would expect a screen reader to read that character independent of the punctuation settings. When reading word by word, sentence by sentence, line by line etc, then punctuation settings should be respected. In case of the window title, I also agree that NVDA should not just ignore the character in the title bar or status bar unless there are other characters displayed in that bar.

@JulienCochuyt
Copy link
Collaborator

JulienCochuyt commented Sep 9, 2019

There indeed are two issues here:

  1. Verbosity settings might dictate that no character in a given chunk of text should be spoken, leading to silence while there is content.
  2. A single character is quoted, visually emphasizing it, in which case it has a much stronger meaning than expected by the verbosity settings.

Point 2 is pretty hard to address correctly in all situations. Cf. earlier comments regarding the many quoting styles in different languages. Addressing it for cases like '?' and "*" is probably feasible, though.

Regarding point 1, later comments make me consider it differently: The trigger of a change of behavior should not be that there is a single unspoken character, or that there is a series composed exclusively of the same unspoken character. It should IMHO be triggered by the fact that a reviewed chunk of text leads to silence. In this case, a possible strategy could be to incrementally raise the verbosity settings for that chunk of text until something is announced. This strategy should probably be considered differently for review and say all commands, though.

@DrSooom
Copy link

DrSooom commented Sep 9, 2019

@Adriani90: Of course it could be enabled by default, but I as the end user always want to have the power to disable this – and not giving over that power to the developers to choose a firm decision for the end user, especially in that case with hundreds of language and TTS combinations. Furthermore it's better for the developers to give the end user both options, otherwise another user is going to open a new issue because he want to have the previous behavior back.

btw: The question mark could also be surrounded by round or squared brackets on websites such as (?) or [?]. In most cases that question mark with or without the brackets is defined as a link. I just wanted to mention this to keep that in mind for testing.

@JulienCochuyt
Copy link
Collaborator

because he want to have the previous behavior back.

Leaving aside the question of quoting, do you really think that a user might reasonably wish to be presented with silence as the result of an action? I sincerely doubt so.

@DrSooom
Copy link

DrSooom commented Sep 10, 2019

This could be the case if the Unicode character isn't spoken correctly by the TTS and if the end user uses a braille display at the same time. And personally I prefer "A B C D E (nothing) F G H I J" from the above given example. And we should not only think about Germanic and Romanesque languages. CC: @josephsl and @nishimotz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants