Re: How can I remove all descriptions that define the format of a document in NVDA?


 

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

Join nvda@nvda.groups.io to automatically receive all group messages.