Fair warning:  This is the last topic you're going to get to start on this.  Three in two days is MORE than too many.  Any further topics will be locked and deleted.
--

It used to be understood that if you published and profited from a mass media platform you should also be responsible for its content. That idea is nowadays considered quaintly archaic. There is no real accountability, and almost limitless ability to post any kind of ridiculous and scurrilous nonsense. God help us.

       ~ Ross Goldbaum, Letter to the New York Times,

          Regulating Media: It’s Now Seen as a Quaint Idea, November 13, 2022

The only way you can do any of what you want to do now is to use the speech dictionary.  While you wouldn't want to have single words like button silenced, phrases that you never run across such as can be edited, can be silenced without you missing text. 

You said we shouldn't suggest that you use the speech dictionary.  I'm simply pointing out that you have a choice, either do nothing or use the speech dictionary in ways that won't interfere with words you will run across in general use.  You certainly aren't going to run across can be edited or some other phrases you don't want spoken in general use.  You can use the dictionary to silence those phrases without conflicts.

Gene
On 11/17/2022 12:54 PM, z9zyt0@... wrote:

You really don't seem to get how this request comes across, but, that's beside the point.  NVAccess has used GitHub for as long as I've known about NVDA as a mechanism for filing bug reports or feature requests (and yours is NOT a bug, it's a request for a change in behavior, a new feature).

Creating a Github Account

Creating an Issue in GitHub for NVDA

NVDA_Feature_Request_Form_Template.dotx

MS-Word Fillable Form for an NVDA Bug Report Including Pre and Post Filling-Out Instructions

MS-Word Fillable Form for an NVDA Bug Report Including Only Post Filling-Out Instructions

How to Unprotect a Completed Fillable Word Form so the Entire Document Can Be Copied

--

It used to be understood that if you published and profited from a mass media platform you should also be responsible for its content. That idea is nowadays considered quaintly archaic. There is no real accountability, and almost limitless ability to post any kind of ridiculous and scurrilous nonsense. God help us.

       ~ Ross Goldbaum, Letter to the New York Times,

          Regulating Media: It’s Now Seen as a Quaint Idea, November 13, 2022

I see that Brian has discussed filing a request on Github.  Since the chances of anything being done are next to nothing, the only plausible way you have of stopping some of the information you want to stop is with the speech dictionary. 

Gene
On 11/17/2022 9:25 PM, z9zyt0@... wrote:

Well, it's not fair that NVDA adds features and doesn't leave the possibility to disable them, that's not fair.

Hello,

I happen to be an NVDA developer (although I don't write NVDA code in an active basis, I can answer some questions about it). Let me try my best to explain the situation so we can come to an understanding as to why I'm about to say what I will say regarding this issue:

Short answer: no solution unless developers are willing to get rid of an important thing that makes graphical user interfaces and accessibility possible.

Explanation: if I understand the issue correctly, the request is to turn off additional wording in document formatting such as "tree view," "alert," and others to make it more efficient for users. Yes, you can turn off announcement of things such as "tables," "links," and so on, more effective in web browsing contexts.

I'm sorry to inform you that you can't really disable announcements such as "alert" and "tree view." I think there is a bigger issue, and don't take what I'm about to say too harshly:

I think there is a confusion happening regarding format markers and control roles/types. This may stem from the fact that, in some cases (say, in web browsers), some things can be seen as both a format marker and a control type. For example, in web browsers, a link is indeed a control type, but it can be seen as a format marker (visually, a link is presented quite differently such as a different color compared too surrounding text), ultimately due to the fact that web content is based on document markup and other code.

Based on this, I think a much better way to explain the situation is turning off control type/role announcements. I can talk about a short-term solution, but before doing so, I must explain a high-level overview of how NVDA announces things like "alert" and "tree view":

NVDA can say "alert" and "tree view" depending on what software developers say what a control is. If the control (or something that is seen as a control inside a document in this context) exposes the right information about itself (through accessibility API's), then it makes sense for a screen reader such as NVDA to inform users as to what that control is. Doing so:

1. Acknowledges the code written or communicated by app developers.
2. Shows that NVDA is communicating with the accessibility API used to access information about an app or the control in question.
3. Informs and reminds users about what the control is and how to interact with it.

There are at least 140 control types defined in NVDA. Only a subset of them such as links, headings, frames, tables, and so on can be seen in document formatting settings panel because these are common ones encountered in various situations, most notably when editing documents in apps such as Microsoft Word and when browsing the web. This is because in addition to being a control type, these can be interpreted as format markers (heading in Word document, for example).

I think what you are really asking for is the ability to toggle control type announcements. There is an add-on "that will solve" the problem in a creative way (note the quotation marks): using sounds to indicate role (control type) announcements. We could perhaps say that we want an add-on or a feature change in NVDA to toggle control type announcements, and this is possible... no, wait, impossible, actually. Here's why:

What makes screen readers effective, or as some folks could say, efficient? If you think the answer is verbosity, you might be traveling on a road that could one day intersect with "screen reader street." If you think screen reader features, perhaps you might be walking on a street that may or may not intersect with "screen reader street." If you think it is reading different screen content, perhaps you might be standing very close to the "screen reader street."

I think what truly makes (or breaks) screen readers is not verbosity, features, nor content reading. It is information accuracy in a vast ocean filled with possibly conflicting data. Information accuracy for screen readers is informed by choices made by humans:

1. App developers because they are the experts who can tell you things about the program you are working right now.
2. Accessibility API developers because they bring their own understanding of accessibility to the table, and in many cases, influence app and screen reader developers.
3. Screen reader developers because they must show care when interpreting accessiblity data such as accuracy of control type or other information the app says to users.

One important information gathered when working with a control is its role (control type). Depending on how the screen reader processes it (or perhaps announce or not announce it), users will get different experiences due to changes to information accuracy:

• Role is announced in some form: at least users can be reminded of what the control is and use strategies such as muscle memory to interact with it.
• Role is announced differently: how users feel abot effectiveness and efficiency of this approach depends on who you ask. A seasoned uses may know what's going on, but a new user may not.
• Role is not announced: it now comes down to how users and app developers understand the picture. If the control type doesn't change, then the user may experience some form of "accuracy" (or not). But if the control changes somehow (say, label is different) or the control type completely changes (same label but changed to a checkbox instead of a radio button which users may have been used to), then it defeats the purpose of removing role announcements because what users thought was accurate is no longer the case (false negative; although used in research and statistics, a false negative condition that is incorrectly marked as accurate is more harmful than a false positive).

To sum up the discussion in front of me: NVDA must navigate an information ocean, striving for information accuracy while acknowledging information blackout. Control type announcement happens not at the speech level, but at the level of accessibility API's - whatever the pap says what the control is, that's what the accessibility API will say, and from that moment NVDA will say whatever it is told to say. People can change things here and there such as turning off announcements of format markers that are control types in their own right. But consider: there are times when efficiency makes sense, but for this issue, it affects information accuracy.

The point I wanted to teach people through this lengthy response is that, although suggestions such as turning off things to make the experience more efficient sounds fine, but when you think more critically about it, a feature request such as this one may not be feasible. More bells and whistles (including silencing some data) could decide the reputation of a screen reader, but they cannot surpass the bigger picture of accurate scales and weights (don't forget about measurement units, and for some, impact of gravity). So my honest opinion about the feature request to toggle control type announcements: more harm than good (sorry; note that this is my opinion so it does not reflect positions of other developers).

Hope this helps a lot.

Cheers,

Joseph