ability to shorten longer announcements on web pages like heading level x, etc.

[hozosch]

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

It is not a problem in the sense of a bug, but it is something that was brought to my attention by one Jaws user who's getting more and more into NVDA.

Describe the solution you'd like

IN Jaws, you can shorten those announcements as described in the title of this issue, or even replace them with sounds and such. I understand the issue of copying anything from a different product, but I also think those who see this as a problem should be able to eliminate it, that is, being able to shorten the heading announcements if they so wish.

Describe alternatives you've considered

So far, the only way is to do it in the dictionary, but that would mean it would be shortened everywhere, which is perhaps not really what you want. Another way, if you're geeky, is to modify the translation file for yourself if it's a different language, but that's not good either. Maybe though, this doesn't need to be integrated in the core, an add-on would do the job just fine as well.

Additional context

[mltony]

Could you describe in more detail how does Jaws do it? If you replace the whole announcement with an earcon, then you lose information about the level. Does it also allow replacing "Heading level" with a user-configurable string?
FWIW I am now working on extending my Phonetic Punctuation addon, one of the new features is going to be replacing role announcements (e.g. "heading") with earcons. As for the level, I was thinking about setting synthesizer pitch depending on heading level, but can consider alternative rules.

[hozosch]

Yes, a user configurable string is what I mean. For example, h1, h2 etc. is what I was thinking of, and that's also how Jaws can be customized from what i understand.

[burmancomp]

I think there is a related discussion #14942.

[Adriani90]

I Think this would be a really good start to provide different levels of verbosity. Imo we should predefine the short versions, same as we do for commandline switches for example. In that case every element type in document formating settings could be a combobox instead of a checkbox, having following options:

• long pronounciation
• Short pronounciation
• Custom pronounciation
• Earcon

[Adriani90]

When the user chooses custom pronounciation, a syntax needs to be entered in to an edit field, e.g. „h(number)“. However, this would be challenging to implement because then it needs to sync with the coresponding translated string. We want to avoid having to enter a custom pronounciation e.g. for every heading level separately.

[CyrilleB79]

I guess that allowing to customize some strings of the UI, as in the feature provided by Jaws, i.e. replacing "Heading {n}" to "H {n}" may be quite easily doable. The idea would be to replace the standard _() gettext function by a dedicated one, adding an extra layer to the translation framework. This dedicated function should return the shortened custom string if provided by the user instead of the normal translation. Whether this custom string should be language dependant or not need to be decided (both are possible).

Instead, if a choice is made to allow to configure how formatting is reported, I'd recommend to think of a reorganization of Document formatting settings panel so that it remains understandable. We have already begun to introduce additional controls defining how thing are reported, rather than what is reported. IMO this makes this dialog less readable.

[ABuffEr]

I guess that allowing to customize some strings of the UI, as in the feature provided by Jaws, i.e. replacing "Heading {n}" to "H {n}" may be quite easily doable. The idea would be to replace the standard _() gettext function by a dedicated one, adding an extra layer to the translation framework. This dedicated function should return the shortened custom string if provided by the user instead of the normal translation.

I like this idea, even more if generalized (a single dialog where customize all messages). It could provide both speech and Braille customization, maybe.

[Adriani90]

Note that making reporting shorter or longer is also requested regularly by braille users as well. I propose following redesign of the document formating settings, cc: @SaschaCowley what do you think?

It seems WX python 4.2.2 allows for cutom 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. Something like we can already see in the Windows explorer when opening the folder options. There is a tree view with advanced settings.
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: Basically we would need 3 tree levels:

• Group of settings level 1 (e.g. table information)
  • Setting item level 2 (e.g. table headers)
    • For some items, we need Sub setting level 3 (e.g. radio buttons for rows, columns, rows and columns, or disabled)
  • On level 2, where settings items without any children sub settings (e.g. report font attributes), we could preserve the checkboxes like we already have but as tree elements with two states (checked or not checked).

Step 2: when you are on the lowest tree level of the parent node, and this is a radio button (e.g. child item of table headers = "rows and columns radio button level 3"):
• Focusing and enabling a radio button other than “disabled”, leads to two combo boxes conditionally displayed, and 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

Obviously the combo boxes would not appear if you choose “disabled radio button"" in the tree view.
Same conditional principle would apply if you focus a checked checkbox (e.g. reporting font atributes on level 2) The two combo boxes would be displayed conditionally.

The advantage of this approach is that the user can adjust its reporting needs in a very flexible way. I admit this is a complete redesign of the document formating settings, but this is really worth for being ft for the future.

[Adriani90]

And this is already usual patern well known by blind users from the Explorer folder options tree view.

[seanbudd]

@Adriani90 - can you open a separate issue for that proposal? it's somewhat offtopic here

[SaschaCowley]

Somewhat related to #16695and #9738

[Adriani90]

@seanbudd it's not off-topic, actually it is a proposal to solve this in a broader scope as requested in #46. But yeah I am happy to open a new request with my proposal.