Closed nvaccessAuto closed 7 years ago
Comment 2 by halim on 2013-12-07 11:12 Ok this very old ticket describes a realy annoying problem with nvda's braille display output.
A verbosity level would also help people with smaller braille displays. Writing all status stuf compleetely wastes much space on the display. It should be considered to use replacement patterns like (x) for radio buttons. Afaik nvda displays (X) and displays aditionaly the word radio wich could be stripped of with some sort of verbosity level.
In the last few months, I've heard several complaints about this from Dutch mailing list members and @BabbageCom customers. In #1885, I posted the following idea which might be a possibility for this issue as well:
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 items from object presentation seem to be relevant:
- Report object shortcut keys
- Report object position information
- Report object descriptions
Additional options which should be tog gable:
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. However, that's a minor detail and can be sorted out later.
This issue is getting rather confused. It first talks about disabling roles, but then others have commented about shortening the text for states (which is something we've already done for some states and could easily do for others if people have intuitive suggestions). Now you're discussing separate configuration of formatting for speech and braille, which is covered by #1885.
The bigger question for me here is use cases. If you disable role, states, focus ancestry, etc., you're losing information which is essential to understand the user interface. Is this primarily intended for users who use both speech and braille and get the other information from speech? Or is it intended for users who know the application they're using so well that they don't need this information? Use cases are essential for us to justify something being implemented.
This issue is getting rather confused.
May be we should split it out to multiple ones?
The bigger question for me here is use cases. If you disable role, states, focus ancestry, etc., you're losing information which is essential to understand the user interface. Is this primarily intended for users who use both speech and braille and get the other information from speech? Or is it intended for users who know the application they're using so well that they don't need this information?
You already have two valid use cases here. I think there are at least four types of screen reader users in terms of how they use speech and braille:
This issue is still a bit vague in scope. I suggest closing it in favour of newer issues that have a clearer scope and goal. @dkager, thoughts?
Sounds reasonable.
Reported by jkinnunen on 2008-10-27 16:35 The amount of information that is shown in braille, such as the role labels, should be made configurable. Perhaps we need some kind of braille verbosity levels?