Quick navigation to font attributes

[LeonarddeR]

Initially suggested in #4684 (comment)

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

As a blind user, it is pretty difficult to analyse the formatting of text in an efficient way. If you really want to be sure that the layout of a document is correct, you either need to do one out of several options:

1. Read the whole document with all relevant NVDA's document formatting settings enabled
2. Convert the document to a format that exposes certain attributes using code, such as html or mark down, and assess the results. This most likely doesn't include several MS Word specific attributes, such as style.
3. Ask a sighted user to do a final assessment of the document.
4. Use something like the JAWS Text analyser

Describe the solution you'd like

I would propose a separate layer of quick navigation keys that, instead of moving to elements in a document, moves to text in the document with a specific attribute. For example

Key	Attribute\
a	alignment change
b	bold
c	color change
d	any change in formatting with the current text
e	emphasis
f	font name change
i	italic
l	line spacing
n	Underline change (i.e. underline when current text is non-underlineand vise versa)
s	different font size
t	Italic change(i.e. italic when current text is non-italic and vise versa)
u	underlined text
w	weight change (i.e. if the current text is bold, move to non-bold and vise versa
y	style change

This layer could be enabled by enabling browse mode with NVDA+Space. The single letter navigation toggle (shift+NVDA+space) could be changed to cycle between content quick navigation, layout quick navigation and quick navigation off.

Quick tests revealed that implementing this shouldn't be at all difficult for MS Word using UIA. Having said that, I think it should be possible to implement this for most if not all textInfo implementations that expose formatting information. However, it is most likely that performance can be a real culprit here.

[LeonarddeR]

I've put some research into this:

1. Implementation for virtual buffers is probably very easy, we just have to introduce additional node types with associated attribsin _searchableAttributesForNodeType
2. For UIA, it is more difficult, as for bold and italic text for example, it looks like our iteration stops at every single word that is bold or italic, even when we're dealing with a line that's completely bold or italic.
3. Introducing an additional layer of quick navigation keys is hard to build in the current system where one gesture may be associated with only a single script. I have the feeling that Improve appModules to be able to maintain support for several versions of an app #10248 might come in handy here. We could create overlay classes for every layer that hold the quick navigation scripts for the layer and switch overlays on the fly.

I'm afraid that every alternative will result in scripts not being assignable in the input gestures dialog.

[JulienCochuyt]

I'd like to submit here an alternative solution to this problem that does not involve quick navigation.
Original idea from @frederic-brugnot

1. Find dialog

The Find dialog (NVDA+control+f) could be complemented with the ability to search for:

• Text matching the formatting at the current position
• Text not matching the formatting at the current position
• Any formatting attribute
  In this later mode, to help with defining formatting attribute criterion, the user could be provided with a set of drop-down lists pre-filled with all the different values found on the document.
  Eg. if text is only present in black, red and green in the current document, propose those three colors for selection rather than a color picker.
  For performance sake, the formatting attributes values present in the document should of course be aggregated only when this search mode is selected.

This way, one could easily jump back and forth to any specific formatting using NVDA+F3 and NVDA+shift+F3.

2. Elements List dialog

The Elements List dialog could be complemented with an additional type: "Formatting"
When selected, the same set of drop-downs would offer to specify the criterion to match.
The list of elements would then be populated with all matches, maybe presenting their line number.

This way, one could easily review at a glance all text with a given formatting.

This would probably need the performance issues of the Elements List dialog to be addressed first.

When proof reading the formatting of a document, both 1. and 2. could allow one to easily notice eg. the presence of an unexpected font type in the "Font" drop-down.

[LeonarddeR]

@JulienCochuyt: thanks for your idea! I like the idea about the find dialog, but will that also work in cases where you're only searching for certain formatting, without providing the text itself?

[JulienCochuyt]

@JulienCochuyt: thanks for your idea! I like the idea about the find dialog, but will that also work in cases where you're only searching for certain formatting, without providing the text itself?

Indeed, Frédéric's intent was to allow searching both by text and formatting at the same time.
If one wishes to search only by formatting, the text field would just need to be emptied.

[Qchristensen]

As a workaround for some of the original issues, the BrowserNav add-on provides keystrokes to jump between text of the same alignment or font / font style: https://addons.nvda-project.org/addons/browsernav.en.html (I haven't tried it, but reading the description it appears it works in "Browse mode" rather than just "browsers" but I could be wrong).

As another method to achieve part of what is suggested, you could ensure you have all the document formatting options set in NVDA, then turn on NVDA's speech viewer, set NVDA to read all the document, then search the speech viewer text for terms indicating a change such as "alignment", "color" or "font" (which, after the initial state, would then only be read as those things changed).

(I'm not disparaging the original suggestion, which I think has merit, just offering a couple of workarounds in the meantime).

[cary-rowen]

This is a useful feature request, and I prefer what @LeonarddeR proposed in the original description.

[ABuffEr]

Hi,
even if it adopts a different approach than ones proposed here (that remain both valid, in my opinion), you could be interested to my just released, experimental add-on, where I mainly worked on a filtered view feature (making experiments with formatting analysis).