For anyone who reviews this, it might be easier to forget about the diff and just look at the makeSettings en onSave methods on DocumentFormattingPanel. The diff is very hard to read.

Hello

Some global comments on this PR:

I agree that the document formatting panel needs to be simplified and that tabbing through all its elements is long. However I have listed some existing downside in this PR and in the conversion of all options in checkbox list:

1. In the old version of the document settings panel, it was very handy to hear the accelerator key when tabbing to items, e.g. to know that Alt+K could be typed to go directly to "Links" item next time. Now that all is grouped in lists, the individual items have no more accelerator and the accelerator key of the list it belongs to is not heard when tabbing into this list. E.g. "Alt+T" is not heard when tabbing to the "Table information" list.
2. Splitting the combobox in 2 checkbox (for "Line indentation reporting" and "Cell borders") seems less clear to me.
3. Following point 2, adding future options that would require more than 2 states would be less clear. The two future option I have already thought to (and needed at least one time) are:

• Font attributes: allow to report only some of them but not all or None (with checkable list onlyy for this item or with a 3-option combobox None/All/Personalized and a button to open a dialog to select only some of them)
• Row/column headers: allow to report None, Row, Column or Row+Column headers in tables (4-option combobox)

This list is here only to be discussed and again, I agree however that document formatting settings panel nees to be simplified.

Some global comments on this PR:

Thanks for these!

1. ... the accelerator key of the list it belongs to is not heard when tabbing into this list. E.g. "Alt+T" is not heard when tabbing to the "Table information" list.

This makes sense. I think we must be able to fix this.

2. Splitting the combobox in 2 checkbox (for "Line indentation reporting" and "Cell borders") seems less clear to me.

We could consider leaving these as combo boxes.

3. Following point 2, adding future options that would require more than 2 states would be less clear.

I guess we can still decide this on a case per case basis.

2. Splitting the combobox in 2 checkbox (for "Line indentation reporting" and "Cell borders") seems less clear to me.

We could consider leaving these as combo boxes.

Hmm, splitting "Line indentation reporting" into two checkboxes isn't really a problem. But "Cell borders" … I'm not sure here.

btw: "Font attributes" should get their own list with checkboxes for each attribute type (bold, italic, etc.). I'm not sure, if an issue for this feature request already exists, but it's in my head for many years, because it's useful for online shops (keyword: strikethrough price). Adding a new window for customization isn't user-friendly.

And the row/columns headlines can be split into two checkboxes. A combo box with four entries isn't really required here too – in my opinion.

btw: "Font attributes" should get their own list with checkboxes for each attribute type (bold, italic, etc.). I'm not sure, if an issue for this feature request already exists, but it's in my head for many years, because it's useful for online shops (keyword: strikethrough price). Adding a new window for customization isn't user-friendly.

This point has to be discussed in a separate issue however. Tis PR aims only to convert to checkbox list where possible, keeping the feature of existing panel.
In my previous comment, I talk about this feature only to say that we should ensure that it will be possible to implement it with the new panel layout.

@CyrilleB79: I know. 😉 Maybe we only have to extent issue #6438. See also: Issue #1885

See in #9355 another proposal of ternary option that would have an impact on this PR if merged.

if we really want to introduce more ternary options, I think a checkable list is just not suitable for document formatting options, or we should keep these as separate combo boxes. I don't share the concerns regarding the cell border options though.

@LeonarddeR I agree that the cell border option example is disputable. I have never used these options nor heard of any example in real life where they would be used.

However IMO, Line indentation reporting and graphics reporting (if implemented) options would remain clearer from UX point of view if they remain a combo-box and if a unique script is dedicated to toggle combo-box value.
What is your thought about that?

How about introducing a tree view with expandable and colapsable elements = groupings, something like in the input gestures dialog? In this case every option in the expanded grouping could have more states, i.e. you can change the state by pressing space bar on the option. NVDA would report the name of the option along with its currectly selected state when navigating through the tree view. That means the options with checkboxes would have to be changed and show the states "on" or "off" instead of a checkbox. Other options could show any other state like (tones) "tones and speech" etc.

How about introducing a tree view with expandable and colapsable elements = groupings, something like in the input gestures dialog? In this case every option in the expanded grouping could have more states, i.e. you can change the state by pressing space bar on the option. NVDA would report the name of the option along with its currectly selected state when navigating through the tree view. That means the options with checkboxes would have to be changed and show the states "on" or "off" instead of a checkbox. Other options could show any other state like (tones) "tones and speech" etc.

That would be an user experience like JAWS has. I think something like that would be more useful to have for the complete settings tree instead of only the document formatting settings.

@feerrenrut What do you think about #10448 (comment) and surrounding comments? I'd like to bring this in a state in which you can review this.

Would implementing a tree view like the one used for advanced folder options in Windows Explorer with checkboxes and radio buttons be acceptable here? IMO it eliminates all currently existing problems:

1. It would be possible to jump to the given item with first letter nav, so the problem of not reporting shortcut keys no longer exists.
2. The visual issues related to checkable lists would also be gone.
3. Tree views are not exhibiting these redundant focus announcements.

@LeonarddeR Wrote:

if we really want to introduce more ternary options, I think a checkable list is just not suitable for document formatting options,

It looks like we do. See #10474 (comment) for an example.

@LeonarddeR apologies for not providing feedback yet. I'm trying to work through bug fixes and "apparently ready to go" pull requests first. I hope you understand.

Previously you have asked about priority of this. I agree there is definitely an opportunity to improve the UX of this panel, and a list could be extended to support filtering, sorting, an enable / disable all. But I don't think the current UX is so bad to need to put a priority on this.

@feerrenrut What do you think about #10448 (comment) and surrounding comments?

I'm not sure what the specific question is, but here is what I think after reading those comments:

In terms of "tri state" options, it might be worth investigating "list/table" types that allow an arbitrary control in a cell. Then the first column could contain a checkbox in some cases and a combobox in others?

As per the description of the PR "Scaling issues, see #8635" don't worry about this here. Now I'm familiar with the problem I see it in lots of software on windows! Not ideal, but not a showstopper either.

Given the fact that @feerrenrut pointed out that this doesn't have much priority yet, I'm abandoning this.

From the description it seems like there were a few minor issues to fix on this PR, which someone is welcome to continue on.

If I assume the main "itch to scratch" with this PR is to make it faster to toggle the one setting you are looking for (rather than explore what settings are available), then I think a filter would be the most user friendly way to achieve that.

hello all
Any current updates on this PR?
Again, this pr is mentioned because
@SaschaCowley
Improvements under way
Separate object information reporting into speech and braille
Separate table information reporting into speech and braille
Separate document information reporting into speech and braille
Separate element type reporting into speech and braille
and
Separate font attribute reporting into speech and braille
With more and more options for document formatting settings, clear categorization may be needed.
It is suggested that can make a clear grouping of the checkboxes in the document formatting settings gui.
BTW: The current Select NVDA Modifier Keys are also using a list interface similar to this pr
Based on the above example, it is recommended to restart this pr
thanks