Repository: nvaccess/nvda

Issue:
NVDA announces "Article" before every article while browsing the articles via quick keys
<!--
Please thoroughly read NVDA's wiki article on how to fill in this template, including how to provide the required files.
Issues may be closed if the required information is not present.
https://github.com/nvaccess/nvda/wiki/Github-issue-template-explanation-and-examples
-->

### Steps to reproduce:
1. Start NVDA
2. Open a web page containing the articles (Such as twitter or mbasic.facebook.com), and (If required) go to NVDA input gestures settings and asign the reading of the next and previous article on a quick key.
3. Turn on the reporting of the articles from NVDA document formatting settings.
4. Now navigate on the web page via quick key which you have just asigned for navigating to the articles
5. It can also be verified without asigning any quick key for the articles by using just heading navigating command "H"
6. Observe, NVDA reports "Article" before every article even though browsing via quick key (no matter it is specifically for article reading or heading navigation) which is very annoying. (It doesn't happen other elements when we use the quick keys.
### Actual behavior:
if we turn on the article announcement from the "document format settings", NVDA announces the "article" before every article even though browsing it via heading navigating quick key: "H" or specifically asigned article reading quick key..
It is very problematic and time consuming to here "article" with every element such as: headings while browsing.
### Expected behavior:
When we use the quick keys to navigate to the articles on a web page, the article text/label should be announced first and then "article" should be announced after it,
### System configuration
#### NVDA installed/portable/running from source:
Tried with both
#### NVDA version:
Tried with all the versions till latest alpha.
#### Windows version:
Windows 10 19041.208
#### Name and version of other software in use when reproducing the issue:
Any of the web browser/electron app
#### Other information about your system:
Tried on latest fast insider builds too
### Other questions
#### Does the issue still occur after restarting your computer?
Yes always
#### Have you tried any other versions of NVDA? If so, please report their behaviors.
Yes all. Same behaviour/issue
#### If addons are disabled, is your problem still occuring?
Yes
#### Did you try to run the COM registry fixing tool in NVDA menu / tools?
Yes



Discussion:
As the implementer of article, I think I did this on purpose, as this is also the behavior for ARIA landmarks. If you navigate a page with d, for example, you will also hear the landmark announced first.

I however agree that for article, at least those without a label (and I think hardly any have one), this should be changed.
This requires a change in speech.getControlFieldSpeech, the speakContentFirst variable. Marking as good for new dev.
However, given the amount of quick navigation keys which can be reassigned, Users, especially beginners, might forget at some point which key is for which element if this is not reported. You can disable the reporting of articles in document formatting settings and still use the quick navigation key which you assigned. Or is this not working?
You're right bro, but if we turn off the article reporting, then let's say we are navigating via arrow keys, then too we won't be able to know whether we landed on an article. :(
> However, given the amount of quick navigation keys which can be reassigned, Users, especially beginners, might forget at some point which key is for which element if this is not reported. You can disable the reporting of articles in document formatting settings and still use the quick navigation key which you assigned. Or is this not working?


> This requires a change in speech.getControlFieldSpeech, the speakContentFirst variable. Marking as good for new dev.

Wow, what's this label? name looks interesting though.
Yes, people don't define the name/labels for the nearely all the articles. so for the unnamed articles, it can be changed.
> As the implementer of article, I think I did this on purpose, as this is also the behavior for ARIA landmarks. If you navigate a page with d, for example, you will also hear the landmark announced first.
> 
> I however agree that for article, at least those without a label (and I think hardly any have one), this should be changed.


@leonardder wrote:
> I however agree that for article, at least those without a label (and I think hardly any have one), this should be changed.

I agree. If ever an article has a label, your first implemented behavior is preferable, notably as it helps discriminate the label from the content.
When there is no label (vast majority of cases), I guess "article" could be omitted altogether when (and only when) using quick nav by article.
[offtopic] Once again, I'd really prefer a default gesture be assigned to this quick nav, as many users do not even know how to assign these. [/offtopic]
@akash07k if you are using arrow key to navigate, I guess the "article" reporting is not important since you are looking for the content of the article. Most articles have also a heading or a link atribute as well. So actually the article atribute is meant only to really boost efficiency while navigating on a website by a quick navigation key. It's only my opinion, but I think reporting of articles might be useful for beginners, but for advanced users the reporting can be turned off in the document formatting settings.
@Adriani90 Hmm, you are right, but, that way if we'll browse via arrow keys, then we won't be able to know that this page contains the articles at all.
For identifying that, we'll have to explicitly press the article navigation key so that we can know whether there are articles or not.
For example, on the getpocket.com site, every post/article is wrapped in article tag and they are not using any heading tag at all. In that case, if we navigate via arrow keys, then we won't be able to browse that efficiently. However, I'll try to get habitual with your suggestion.
> @akash07k if you are using arrow key to navigate, I guess the "article" reporting is not important since you are looking for the content of the article. Most articles have also a heading or a link atribute as well. So actually the article atribute is meant only to really boost efficiency while navigating on a website by a quick navigation key. It's only my opinion, but I think reporting of articles might be useful for beginners, but for advanced users the reporting can be turned off in the document formatting settings.


@akash07k the quick navigation key that you assigned for articles will work regardless wether the reporting is on or off. So if reporting is off and you want to find out if there are articles, you just press the quick navigation key. If there are no articles, NVDA will say "no next article" or "no previous article". If there are articles, you will navigate one by one.
@leonardder in case you agree, I suggest to close this issue to keep the consistency with all other reportings in the document formatting settings.

@Adriani90 No this is not right. I already know that article navigation quick keys work regardless of the article reporting on/off in document format settings.
I'm saying that if we'll turn off the article reporting from the document formatting settings then we'll not be able to know if there are articles on the page if we navigate via arrow keys and not via quick keys.
And if we'll turn it on then it will cause problems with quick key navigation as I originally mentioned in the issue.
The issue is valid and carries the valid user impact. It should not be closed at all. Rest it's your and teams wish whether you guys want to close it or not.
> @akash07k the quick navigation key that you assigned for articles will work regardless wether the reporting is on or off. So if reporting is off and you want to find out if there are articles, you just press the quick navigation key. If there are no articles, NVDA will say "no next article" or "no previous article". If there are articles, you will navigate one by one.
> @leonardder in case you agree, I suggest to close this issue to keep the consistency with all other reportings in the document formatting settings.


@akash07k I respectfully disagree. The user can easily find out if there are articles by pressing the quick navigatoin key, there is no need for pressing arrow keys to find out if there are articles. Given the workaround by turning off reporting and using quick navigation key, this is consistent with all other elements that you can choose from in the document formatting settings. Why should articles treated differently than i.e. block quotes or groupings or other elements? Inconsistencies would rather confuse users rather than bringing positive impact.
If we think to change this behavior, than this should be done for every element. But I wouldn't advise to do it.
However, since @leonardder implemented this, I will let the decision to him wether this issue should be closed or not.
Ok. your wish.

On 5/5/20, Adriani90 <notifications@github.com> wrote:
> @akash07k I respectfully disagree. The user can easily find out if there are
> articles by pressing the quick navigatoin key, there is no need for pressing
> arrow keys to find out if there are articles. Given the workaround by
> turning off reporting and using quick navigation key, this is consistent
> with all other elements that you can choose from in the document formatting
> settings. Why should articles treated differently than i.e. block quotes or
> groupings or other elements? Inconsistencies would rather confuse users
> rather than bringing positive impact.
> If we think to change this behavior, than this should be done for every
> element. But I wouldn't advise to do it.
> However, since @leonardder implemented this, I will let the decision to him
> wether this issue should be closed or not.
>
> --
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/nvaccess/nvda/issues/11103#issuecomment-623939730

I don't agree with it however.. but.....

On 5/5/20, Akash Kakkar <akash.galaxy07@gmail.com> wrote:
> Ok. your wish.
>
> On 5/5/20, Adriani90 <notifications@github.com> wrote:
>> @akash07k I respectfully disagree. The user can easily find out if there
>> are
>> articles by pressing the quick navigatoin key, there is no need for
>> pressing
>> arrow keys to find out if there are articles. Given the workaround by
>> turning off reporting and using quick navigation key, this is consistent
>> with all other elements that you can choose from in the document
>> formatting
>> settings. Why should articles treated differently than i.e. block quotes
>> or
>> groupings or other elements? Inconsistencies would rather confuse users
>> rather than bringing positive impact.
>> If we think to change this behavior, than this should be done for every
>> element. But I wouldn't advise to do it.
>> However, since @leonardder implemented this, I will let the decision to
>> him
>> wether this issue should be closed or not.
>>
>> --
>> You are receiving this because you were mentioned.
>> Reply to this email directly or view it on GitHub:
>> https://github.com/nvaccess/nvda/issues/11103#issuecomment-623939730
>

@Adriani90 wrote:
> if you are using arrow key to navigate, I guess the "article" reporting is not important since you are looking for the content of the article.

I disagree. It depends on how the page you're browsing is structured and how much junk there is in between. Sure, quick nav by article is a solution once you know what you're looking for, but it is no replacement for the announce made during the "exploration phase". The options in the document formatting settings not only serve the needs of different people, but also the varying needs of a single user.

@leonardder expressed his agreement on the need for a change in https://github.com/nvaccess/nvda/issues/11103#issuecomment-623359727

I expressed mine in https://github.com/nvaccess/nvda/issues/11103#issuecomment-623417246

I'd add that I often receive feedback from users complaining about the high verbosity level of the announces made by NVDA. Many wish to customize/reduce/tailor these announces to their needs.
Being of a technical background, I like to be as much informed about structure as can be, but nevertheless understand how it can sometimes sound excessive to others.

Thank you very, very much for so often trying to route users and change requesters towards existing solutions, increasing their knowledge of how NVDA can be used efficiently and reducing the work load of code contributors.
Still, the change requested in this ticket is easy, and reduces verbosity with no loss of information at all., which in my humble opinion is to be considered as a win-win deal.
@JulienCochuyt Thanks. You explained it very well and I absolutely agree with your point.
> @Adriani90 wrote:
> 
> > if you are using arrow key to navigate, I guess the "article" reporting is not important since you are looking for the content of the article.
> 
> I disagree. It depends on how the page you're browsing is structured and how much junk there is in between. Sure, quick nav by article is a solution once you know what you're looking for, but it is no replacement for the announce made during the "exploration phase". The options in the document formatting settings not only serve the needs of different people, but also the varying needs of a single user.
> 
> @leonardder expressed his agreement on the need for a change in [#11103 (comment)](https://github.com/nvaccess/nvda/issues/11103#issuecomment-623359727)
> 
> I expressed mine in [#11103 (comment)](https://github.com/nvaccess/nvda/issues/11103#issuecomment-623417246)
> 
> I'd add that I often receive feedback from users complaining about the high verbosity level of the announces made by NVDA. Many wish to customize/reduce/tailor these announces to their needs.
> Being of a technical background, I like to be as much informed about structure as can be, but nevertheless understand how it can sometimes sound excessive to others.
> 
> Thank you very, very much for so often trying to route users and change requesters towards existing solutions, increasing their knowledge of how NVDA can be used efficiently and reducing the work load of code contributors.
> Yes, thanks from my side too 🤣
> Still, the change requested in this ticket is easy, and reduces verbosity with no loss of information at all., which in my humble opinion is to be considered as a win-win deal.


Yes @JulienCochuyt +1 on this.
Although this is off topic, but the verbosity/announcements as well as structural information should be customizable/configurable.
> @leonardder wrote:
> 
> > I however agree that for article, at least those without a label (and I think hardly any have one), this should be changed.
> 
> I agree. If ever an article has a label, your first implemented behavior is preferable, notably as it helps discriminate the label from the content.
> When there is no label (vast majority of cases), I guess "article" could be omitted altogether when (and only when) using quick nav by article.
> [offtopic] Once again, I'd really prefer a default gesture be assigned to this quick nav, as many users do not even know how to assign these. [/offtopic]


Hi.

I think consistency is taking a back seat in some cases where NVDA is concerned, which can be problematic.

I think, broadly, until such verbosity can be customised:
1. When using the arrow keys or otherwise, the type of control (link, button, checkbox, article, grouping) should be announced before the text.
2. When using quick navigation keys, the type of control (even landmarks, buttons, links, checkboxes) should be anounced after the text. This is because the user has pressed a specific key to move to the control, so it is assumed that they already know the type of control they are looking for.
@fisher729 what you describe is already the current behavior in NVDA.

I am sorry, I totally missunderstood this issue... Now after testing, it seems only articles has the behavior of being reported before the text. All other elements are reported after the text. I will hide my comments to make the discussion more focused. Sorry for the inconvenience.
I'm working on this issue at the moment, but struggling to understand how to access current active settings. Can anybody guide me where to look to check whether QuickNav is enabled?
Quick nav is enabled by default in browse mode, i.e. when using NVDA in browsers.

> Quick nav is enabled by default in browse mode, i.e. when using NVDA in browsers.

Ah thanks, that explains a lot actually!

Resolving patch:
diff --git a/source/speech/speech.py b/source/speech/speech.py
--- a/source/speech/speech.py
+++ b/source/speech/speech.py
@@ -42,6 +42,7 @@
 	_flattenNestedSequences
 )
 from typing import (
+	Iterable,
 	Optional,
 	Dict,
 	List,
@@ -1692,6 +1693,39 @@ def getPropertiesSpeech(  # noqa: C901
 	return textList
 
 
+def _shouldSpeakContentFirst(
+		reason: OutputReason,
+		role: int,
+		presCat: str,
+		attrs: textInfos.ControlField,
+		tableID: Any,
+		states: Iterable[int],
+) -> bool:
+	"""
+	Determines whether or not to speak the content before the controlField information.
+	Helper function for getControlFieldSpeech.
+	"""
+	_neverSpeakContentFirstRoles = (
+		controlTypes.ROLE_EDITABLETEXT,
+		controlTypes.ROLE_COMBOBOX,
+		controlTypes.ROLE_TREEVIEW,
+		controlTypes.ROLE_LIST,
+		controlTypes.ROLE_LANDMARK,
+		controlTypes.ROLE_REGION,
+	)
+	return (
+		reason == OutputReason.FOCUS
+		and (
+			# the category is not a container, unless it's an article (#11103)
+			presCat != attrs.PRESCAT_CONTAINER
+			or role == controlTypes.ROLE_ARTICLE
+		)
+		and not (role in _neverSpeakContentFirstRoles)
+		and not tableID
+		and controlTypes.STATE_EDITABLE not in states
+	)
+
+
 # C901 'getControlFieldSpeech' is too complex
 # Note: when working on getControlFieldSpeech, look for opportunities to simplify
 # and move logic out into smaller helper functions.
@@ -1788,20 +1822,7 @@ def getControlFieldSpeech(  # noqa: C901
 
 	# Determine the order of speech.
 	# speakContentFirst: Speak the content before the control field info.
-	speakContentFirst = (
-		reason == OutputReason.FOCUS
-		and presCat != attrs.PRESCAT_CONTAINER
-		and role not in (
-			controlTypes.ROLE_EDITABLETEXT,
-			controlTypes.ROLE_COMBOBOX,
-			controlTypes.ROLE_TREEVIEW,
-			controlTypes.ROLE_LIST,
-			controlTypes.ROLE_LANDMARK,
-			controlTypes.ROLE_REGION,
-		)
-		and not tableID
-		and controlTypes.STATE_EDITABLE not in states
-	)
+	speakContentFirst = _shouldSpeakContentFirst(reason, role, presCat, attrs, tableID, states)
 	# speakStatesFirst: Speak the states before the role.
 	speakStatesFirst=role==controlTypes.ROLE_LINK
 


Test patch: