Reported by ragb on 2013-01-26 00:22
In #808 it was discussed the possibility of implementing global space+dots braille keyboard gestures, that is, instead of each braille display driver having its own gestures with braille dots and space bar (also known as chords), having all of those centralized globally. The infrastructure to support these gestures globally was done as part of #808, but no actual bidings were implemented (although one can use those in gestures.ini, if needed).
Currently there are many inconsistant bindings among various drivers, choices were made based on implementor's preferences, other screen reader's bindings, manufacture's recomendations for other screen reader's (in manuals), etc, etc, etc. However, as these gestures can be applied equally in displays having a braille keyboard and a space bar (with a few exceptions, due to device limitations -- read "braiilenote" here). Most of the times, these keybindings (although differently among drivers) are mapped to keyboard commands used for navigating like arrows, page up/down, end, up, enter, backspace, windows+d (minimize all applications), escape, tab/shift+tab,... showGui (and other NVDA commands) are also commonly mapped.
Main reasons and advantages for having global bindings:
- Centralize all space+dots bindings in one place, so new commands are added easily, bugs corrected easily, etc.
- Be consistant in drivers whenever possible. That means if someone uses different braille displays, he won't get confused with different keybindings (whenever applicable, of course; displays are different from one another).
- Advantages on help/support: even if someone has a different device, he can tell other users how to use braille chords. VoiceOver (either in IOS and OSX) has global braille display bindings and it has proved useful when helping one another using braille displays in it, mainly in IOS.
Disadvantages:
- Some keybindings might change, which can cause initial confusion with users.
- Information in display manuals might be very different from NVDA keybidings (if those are documented in NVDA, I don't see this beeing a problem, vendors can also publish this information as they do for IOS, for instance).
- We need to agree on a set of keybidings, sometimes this is not easy :).
My personal opinion (which is kinda obvious) is that we should go for global key bindings in space+dots gestures, because of consistency, better abstraction and easy of maintenance.
Reported by ragb on 2013-01-26 00:22
In #808 it was discussed the possibility of implementing global space+dots braille keyboard gestures, that is, instead of each braille display driver having its own gestures with braille dots and space bar (also known as chords), having all of those centralized globally. The infrastructure to support these gestures globally was done as part of #808, but no actual bidings were implemented (although one can use those in gestures.ini, if needed).
Currently there are many inconsistant bindings among various drivers, choices were made based on implementor's preferences, other screen reader's bindings, manufacture's recomendations for other screen reader's (in manuals), etc, etc, etc. However, as these gestures can be applied equally in displays having a braille keyboard and a space bar (with a few exceptions, due to device limitations -- read "braiilenote" here). Most of the times, these keybindings (although differently among drivers) are mapped to keyboard commands used for navigating like arrows, page up/down, end, up, enter, backspace, windows+d (minimize all applications), escape, tab/shift+tab,... showGui (and other NVDA commands) are also commonly mapped.
Main reasons and advantages for having global bindings:
Disadvantages:
My personal opinion (which is kinda obvious) is that we should go for global key bindings in space+dots gestures, because of consistency, better abstraction and easy of maintenance.