Redesign the document formating settings pannel 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 or a checkbox in the tree view leads to displaying two combo boxes. you can press tab to focus the combo boxes outside of the tree:

1. Choose reporting output combo box: speech, braille, both speech and braille
2. Choose reporting style: long, short, custom, earcon

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.