Separate formatting configuration for speech and braille

[nvaccessAuto]

Reported by ianr on 2011-11-04 16:46
The new braille output added by ticket #202 is very interesting and I definitely see the need for some users.

I use both the speech and the braille output. Personally I prefer the raw text in braille output as I get the majority of my information through speech and often use the braille output to check mangled words or code sections.

I propose a config option to allow the output of the extra information to be enabled or disabled.

Blocking #3492

[nvaccessAuto]

Comment 1 by jteh on 2013-09-03 23:43
This will be more useful if individual settings can be configured separately as noted in #3022 and I think requested elsewhere.
Changes:
Changed title from "Output of control and format fields should have a config option to enable or disable it" to "Separate formatting configuration for speech and braille"

[LeonarddeR]

This ticket is very old, though still interesting. I propose changing some of the relevant check boxes in the document formatting dialog to a wx.Choice with the options off, speech only, braille only, and both speech and braille. The following options seem to be relevant:

• Font attributes
• Emphasis?
• Comments
• Revisions
• Spelling errors
• Line numbers
• Row/column headers
• Cell coordinates
• Most if not all items in the elements grouping

The following items from object presentation seem to be relevant:

• Report object shortcut keys
• Report object position information
• Report object descriptions

[LeonarddeR]

@jcsteh posted a relevant point in #214 (comment)

I think a tab control or radio button allowing you to select whether to show options for speech or braille would be a nicer UX, particularly because some of the options might already be choice controls.

I think a radio button would be quite confusing here. A tab control would be perfect for the document formatting dialog at least.

[rimas-kudelis]

While testing a new table, my co-author noticed that while browsing the Internet, bold, italic and underline emphasis marks appear much more frequently than is practical. In fact, they're so frequent that in the end he suggested me to comment out begemph/endemph rules altogether.
I do believe however that these opcodes may be very useful when reading e.g. scientific text, so I don't quite like the idea of disabling them. Thus I want to remind the NVDA developers of this issue.

[dkager]

I would think that in such a case, hearing bold/italic through speech all the time is equally annoying, hence you would want to turn this off for both speech and braille. That is already supported.

[rimas-kudelis]

@dkager is it possible to disable that indication now? If so, how?
Note, I'm talking about begemph and endemph indicators as specified in the liblouis table as opposed to anything NVDA might be doing before outside that table.

[dkager]

To rephrase my question: is this actually something you want to do only for braille? Or does it make more sense to disable these formatting attributes for both braille and speech?

In either case, changing the liblouis table for this specific scenario sounds like a very bad idea.

[rimas-kudelis]

I think it does make sense to disable these indicators in both cases, when there are obviously too many of them. But in cases when there is a normal amount of these indicators, I can't really say with confidence that tying both speech and Braille together is the best appoarch.

Changing the table is exactly what I want to avoid here. I want to leave these opcodes enabled in the table. But I hope that NVDA will allow the user to choose whether or not font styles will be indicated in the output, and that such choice will be respected. Should the user choose to disable such indication, I would like to expect that NVDA will pass unformatted text to liblouis, or will otherwise tell liblouis not to indicate emphasis. Currently, this doesn't seem to be the case.

Hope this answers your question?

[dkager]

Did you try disabling the relevant Document Formatting options? I agree this should send unformatted text to liblouis. That is, text without typeforms.

[rimas-kudelis]

Well, I haven't because I'm not a Braille user myself (my vision is perfect, considering the amount of time I spend daily staring at the screen). However, the person I worked with on the new table does have these options disabled, but it doesn't seem to help.

[dkager]

Confirmed, I'll open a new issue for it.

[rimas-kudelis]

@dkager: thanks for confirming!

[LeonarddeR]

After thinking about more about this, I propose a restructure of the list of categories in the settings dialog, changing the list into a tree view. It could look as follows:

• General
• Speech
  • Object presentation
  • Document formatting
  • ... Any other category to make the speech category itself less bloated with options
• Braille
  • Translation
  • Cursor
  • Object presentation
  • Document formatting
  • ... Any other category to make the braille category itself less bloated with options
• Keyboard
• Mouse
• Review cursor
• Input composition
• Browse mode
• Touch interaction
• Windows 10 OCR

[DrSooom]

@LeonarddeR: I like your idea. In my opinion we should go this way as it is less confusing as others. See also: PR #10448

[SaschaCowley]

The following, more granular issues have been opened:

• Separate object information reporting into speech and braille #16759
• Separate table information reporting into speech and braille #16758
• Separate document information reporting into speech and braille #16757
• Separate element type reporting into speech and braille #16756
• Separate font attribute reporting into speech and braille #16755

This issue is being closed in favour of the newer, more specific issues.