Redesign the document formating settings panel so it allows for more flexible reporting style and reporting output

[Adriani90]

Is your feature request related to a problem? Please describe.

Verbosity in screen reading is often very high and many users feel overwelmed by the information that is provided, which in many cases might be irelevant or too complex.
Moreover, especially advanced users prefer efficiency over verbosity.
This request can be seen as a sub request of #46 in which users request different verbosity levels on a global scale, other sub requests are #17483, #16695 and #9738.

Describe the solution you'd like

Since we don't have any starting point so far, I propose a redesign of the document formating settings pannel so that we have a good basis for partially fixing #46.

The idea is inspired from the Windows Explorer folder options pannel, where the advanced options are displayed in a tree view containing both radio buttons and checkboxes, and the patern is well known by blind screen reading users since Windows XP.

Proposal

It seems WX python 4.2.2 allows for custom treeview ctrl with expandable items, checkboxes with two or three states, radio buttons etc. So it whould be quite possible to reorganize the whole pannel as a tree, where each element can be collapsed / expanded.
Reference: https://docs.wxpython.org/wx.lib.agw.customtreectrl.html

As of now we have 4 groups of settings:

• Document information
• Pages and indentation
• Table information and
• Browse mode elements.

Step 1 - custom tree view

Basically we would need 3 tree levels:

1. Group of settings level 1 (e.g. table information)
2. Setting item level 2 (e.g. table headers)
   3. For some items, we need more than 2 options, so on level 3 (e.g. radio buttons for rows, columns, rows and columns, or disabled)

• On level 2, where settings items have only checked or not checked options (e.g. report headings, we could preserve the checkboxes like we already have but as tree elements with two states (checked or not checked).

Step 2 - two combo boxes for reporting output and style

Focusing a radio button which is selected or a checkbox which is enabled in the tree view leads to displaying three combo boxes. You can press tab to focus the combo boxes outside of the tree:
Combo box 1. Choose reporting output combo box: off, speech, braille, both speech and braille

• If user chose "off", other combo boxes are greyed out.
• If user chose "speech", combo box 2.1 becomes active, while combo box 2.2. is greyed out
  Combo box 2.1. Choose reporting style: long, short, custom, earcon
  • Long: NVDA's current behavior
  • Short: predefined short speech output style (not really required)
  • Custom: user can type in how the element / fomrating property should be reported by speech
  • Earcon: user hears a predefined sound instead of words
• If user chose "braille", combo box 2.1. becomes greyed out while combo box 2.2. is active
  Combo box 2.2. Choose reporting style: long, short, custom
  • Long: braille output style is same as speech
  • Short: NVDA's current behavior
  • Custom: user can type in how the element / formating property should be displayed in braille
• If user chose "both speech and braille"
  • Both combo boxes 2.1 and 2.2 are active, and the user can choose reporting style for speech and for braille.

So each of the reporting outputs can have its own reporting style.

Step 3 - designing the reporting style

• Long: the reporting is completely pronounced by speech or displayed in braille (e.g. row 1 column 1 for table cell coordinates, or heading level 1 for headings)
• Short: a pre-defined term is pronounced or displayed in Braille. We have this already for braille, but not for speech. (e.g. r1 c1 for table cell coordinates, h1 for heading level 1)
• Custom: the user can enter a specific syntax in an edit field to design the reporting (e.g. h#, so that all headings are pronounced as h1, h2, h3 etc. depending on their level.
• Earcon: a sound indicates the attribute instead of pronouncing it. This would ofcourse be availabel only if the reporting output is set to speech.

Describe alternatives you've considered

Solve the referenced issues separately, but this might result in a very inconsistent user experience.

Additional context

Other screen readers such as Narator or Jaws provide pre-defined verbosity levels. However, this might be hard to achieve in this community because people prefer flexibility in their own individual configuration which is more than legitimate.

[Adriani90]

@SaschaCowley could you please elaborate why this has been converted to a discussion? From the triaging policy it is not clear to me when requests are converted to discussions and when they are accepted as propper feature requests. This one is properly filled according to template and it has a clear proposal with quite concrete steps for implementation.

[seanbudd]

Apologies for the late response.
If I recall correctly, we expected more community discussion to play out before a final design was settled on.
It seems that this proposal is uncontroversial though.
I'm going to redraft this as an issue unless there's any objections or further discussion in the next week.

[Adriani90]

@seanbudd, @SaschaCowley what should happen with this one? Are you gonna redraft it to an issue? This would be very appreciated.

[gerald-hartig]

@Adriani90 can you please help us understand the specific shortcomings that this proposal would resolve? What are the pain points for users?

[Adriani90]

@gerald-hartig the pain points are also documented in the issues I referenced in the original description above, but I am trying to summarize. I will focus on reporting style, because options regarding reporting output have already been introduced by sascha as an example but only for font attributes.
My understanding is that it is planed to extend these reporting output options to all reporting options in the document formating settings. So this proposal would extend that logic to every option in the document formating settings to give users the flexibility to choose between speech, braille or speech and braille output.

Painpoints and how these are addressed by this reporting style proposal

1. High verbosity when using speech: having the option to design the verbosity of speech for reporting elements / formating would introduce much more flexibility in user experience.

• Through this feature, users can change the output style of speech reporting. Maybe it it is enough to have (I) long reporting style (current situation), (II) custom reporting style (user can enter how the element should be reported) and (III) earcon (predefined sounds for reporting elements instead of pronouncing words).
• This would increase significantly the efficiency for users when using a computer, and would also allow for high level information to be delivered to the user with lower complexity.

2. No way to design the style of braille output according to individual needs: currently users have to stick with the braille output that is defined by NVDA. Having similar options like above would make things much easier

• A combo box with options for braille output style would solve this painpoint, giving the user the possibility to choose between (I) long braille output (similar to speech), (II) short braille output (current situation as already predefined by NVDA), (III) custom braille output (user can define its own braille output style).
• This feature would allow users to set up their own reporting style in line with capacity of their braille displays without worrying too much about number of the braille cells available
• It would also increase significantly the efficiency of blind deaf people when working with a computer
• And users can design their own logic of braille output which might be easier for them to understand compared to the predefined style of braille output of NVDA.

I've adjusted the original description accordingly to consider difference between designing speech and braille output style.

[seanbudd]

We don't find this argument convincing. The related issues are valid and should be tackled - and refactoring these settings would come under that. We believe refactoring before this is a premature optimization and may not be a good use of time. When tackling issues like #46, there is a decent chance and that this premature optimization would need to be completely rewritten and reconsidered.

[Adriani90]

@seanbudd could you please elaborate more on that? How would an alterantive of solving #46 look like? How would you define speech verbosity levels and make sure at the same time the user can customize them?
Implementing this proposal would even make it easier to predefine speech verbosity levels, since we would have to define short and long speech output style anyway.

Anyway, my proposal would fix #46 almost completely, since most verbosity in NVDA comes from this settings pannel and the user would be able to customize that according to his or her needs. Moreover, this proposal would fix other issues that ask for customizability of braille reporting style.
I would find very interesting what others might have to say.
cc: @LeonarddeR, @michaelDCurran, @jcsteh, @CyrilleB79, @cary-rowen, @nvdaes.
In the end, @46 is open since more that 15 years, and to be honnest it seems tackling issues one by one is not really efficient. In some cases we have to think about redisigning from scratch, to really improve things.
And by the way, my proposal is just an advancement of the work already started by @SaschaCowley in #16748. I was just thinking further on that basis and this makes it technically quite feasible in my view.