Add ability to specify which document formatting properties are reported in Braille

[Qchristensen]

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

NVDA has quite a few document formatting options. To conserve space on Braille displays, these aren't all presented. For users relying solely on Braille (either out of choice, out of necessity (eg Braille display but no headphones in a public place) or who are deaf-blind, this can make it difficult to find information about a document.

For instance, I just alt+tabbed to a document I had open in Word.

NVDA speaks: "document page 1 section 1 Calibri light pale red on very dark grey line 5 line spacing Multiple 1.08 ".

NVDA displays in Braille "5 "

(The 5 in Braille is the line number, and in both cases is the text on that line)

There are other ways to get that other information in Barille. For instance pressing NVDA+end to read the status bar will get some of it, but is an extra step.

Describe the solution you'd like

Open to ideas on how best to resolve this. One idea I had was to change NVDA's document formatting options. Instead of having a checkbox for each item. Have a drop down list. The items for each would be: "none" "Speech and Braille" "Speech" "Braille"

The main drawback is that this is a change from the current behaviour where you find the option you want to change and press spacebar to set it. But it wouuld allow a lot more flexibility with minimal learning curve for users.

Also as it is a different data type, it may require converting from the old checkbox (unchecked = none, and checked could either equal "Speech and braille" or the current setting - eg line numbers would be speech and braille, page numbers would be just speech).

Describe alternatives you've considered

We could basically replicate the document formatting options for Braille, but that would be a lot for users to go through.

We could have a "Braille verbosity" setting, but again, that would either need a lot of individual settings, or be arbitrarily decided as to what goes in which verbosity level.

Additional context

Reported today via email (deaf-blind user unable to read information such as page number as it is only conveyed via speech). Has also been reported previously.

[rperez030]

I believe a separate category for Braille makes sense because it is not only about whether something should be presented in braille or not, but how to present it. for example, I may want misspelled word to be presented with dots 7 and 8, or just with dot 8. Maybe we can have the document format category as described in the feature request and a separate category to configure Braille representations. I think we could take inspiration from the Braille Extender add-on on this.

[XLTechie]

I am not a braille user, but I do support them from time to time. I am inclined to agree with the suggestion from @rperez030.

Such a new panel could start out with a replication of existing options from speech document presentation, and be revised from there to be more specific to braille.

It has the advantage of not requiring a config upgrade, and not invalidating a lot of existing community knowledge about how to adjust things in Doc Pres.

[michaelDCurran]

In theory we could do this, though it would be a fairly large bit of work. But before considering this, I would like to verify the primary reason for this. I'm assuming it was the fact we don't report page numbers in braille? If so, the much easier work here is to just solve that specifically. I guess my point is, even if we implemented the broader issue here, that does not necessarily mean that you'd start getting page number in braille, as that is not supported in NVDA's braille code yet. I'd suggest opening a specific issue for displaying page numbers in braille so that can be tracked specifically.

[burmancomp]

I consider this as quite large question. User should have possibility to decide at least: what, how and in which order.

Font attributes are not reported efficiently (what). Clearly they should be reported but how. With dots 7 and 8 or dot 8 or might user define dot/dots if he/she wants. However, this would give only information that there are font attributes (showing this general information should be toggle because if one only reads text, dots 7 and 8 are disturbing). There should be specific mode to present font attributes, and there should be default dot combinations for attributes which user could change.

What about all options found under "document formatting"? And checkboxes, radio buttons, selected and unselected items...? How they should be presented: label, state or role first? And essentially user should have possibility to edit all.

And what if user wants to minimize all extra information so that to get as much as possible text content to display. I guess that requires mechanism to disable/enable things. And user may want to disable/enable things for speech or for braille.

I think that there should be verbosity settings for speech and braille. Should they be separate or not?

There is a discussion #14942 also. Maybe there could be discussed about both braille and speech verbosity.

Back to document formatting. Do we agree that other than basic editing/reviewing text is with braille (without speech) very slow/difficult. No general information about font attributes, no quick way to see where for example underline/bold/italic starts and ends.

Could first small step be that font attributes and for example spelling errors would be presented. User could toggle showing them on/off. When on, they would be shown with given dot/dots (user editable), and then user could query more information with "report formatting". Related issues are at least #3022 and #7097.

[Emil-18]

What about as a first step, make all formatting options shown in braille if turned on via the normal document formatting dialog, and show them the way they are reported in speech, e.g spelling error, some text, out of spelling error, and make this behavior configurable? Yes, it uses up a lot of space, but at least in this way, a user who only uses braille can get the information if wanted

[Adriani90]

In my view the most plausible first step is to add them as kind of an allert message with a timeout. or not? I think this makes most sense especially when you have a lot of words with different formating style etc. In the second step we have to think about a new braille language for displaying formating messages. It could work like with roles and states in the browser with abreviated replacements such as "ht" for highlighted text or "se" for spelling error. Ideally for a spelling error NVDA would display something like Dots 126 SE dots 46 when entering it and Dots 46 SE dots 345 when leaving it.

If we use such a scheme we would never eat more than four characters on the braille display.

Then we would have to think about where to display the messages. I think keeping them as allert messages with a configurable timeout is still the way to go, because then the messages are displayed exactly when entering or leaving the word or character with the caret.

The issue with the window and status bar information and also reporting order for roles and states are out of scope here I would say.