Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign the document formating settings pannel so it allows for more flexible reporting style and reporting output #17500

Closed
Adriani90 opened this issue Dec 11, 2024 · 0 comments
Milestone

Comments

@Adriani90
Copy link
Collaborator

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.

@nvaccess nvaccess locked and limited conversation to collaborators Dec 16, 2024
@SaschaCowley SaschaCowley converted this issue into discussion #17538 Dec 16, 2024
@github-actions github-actions bot added this to the 2025.1 milestone Dec 16, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant