Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HID Braille Driver: add more mappings for arrow keys #14713

Merged
merged 3 commits into from Mar 23, 2023

Conversation

michaelDCurran
Copy link
Member

Link to issue number:

None

Summary of the issue:

Reported by Orbit, The Standard HID Braille driver does not provide mappings to the arrow keys as they would expect.
Currently the joystick can be used for arrow keys and enter, but not the dpad. Some Braille devices, such as the Orbit Reader, only have a dpad and no joystick.
Also, currently space+dot1 and space+dot4 are mapped to nextLine and previousLine braille commands. Manufacturers would prefer that these gestures map to up and down arrow, so that they also work in lists and on the Desktop etc.

Description of changes

When using a Braille Display via the Standard HID braille driver, the dpad can be used to emulate the arrow keys and enter. Also space+dot1 and space+dot4 now map to up and down arrow respectively.

Testing strategy:

Connected to an Orbit Reader 40 with the Standard HID braille driver:

  • While on the Desktop, ensured that the direction buttons of the dpad move the focus in the direction expected, and that dpad enter activates the focused icon.
    Ensured that space+dot1 and space+dot4 emulate up and down arrow and move the focus up and down the icons.

Known issues with pull request:

None known.

Change log entries:

New features
Changes

  • When using a Braille Display via the Standard HID braille driver, the dpad can be used to emulate the arrow keys and enter. Also space+dot1 and space+dot4 now map to up and down arrow respectively.
    Bug fixes
    For Developers

Code Review Checklist:

  • Pull Request description:
    • description is up to date
    • change log entries
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • API is compatible with existing add-ons.
  • Documentation:
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • Security precautions taken.

* space+dot1 and space+dot4 now map to upArrow and downArrow respectively, rather than braille_previousLine and braille_nextLine. In text editing this practicly does the same thing, but in non-text focus, such as in lists or on the Desktop etc, then these gestures will move up and down like with several other braille drivers.
 * A Braille device's dpad  is now mapped to upArrow, downArrow, leftArrow, rightArrow and enter.
"kb:enter": ("br(hidBrailleStandard):joystickCenter"),
"kb:enter": (
"br(hidBrailleStandard):joystickCenter",
"br(hidBrailleStandard):dpadCenter",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should dot8 be in this list?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"bk:dot8" (enter) and "bk:dot7" (backspace) are mapped to scripts in globalCommands.py already as they apply to all braille displays, so don't need to be explicitly mentioned in any braille driver.

@@ -220,22 +220,39 @@ def display(self, cells: List[int]):
"br(hidBrailleStandard):panRight",
"br(hidBrailleStandard):rockerDown",
),
"braille_previousLine": ("br(hidBrailleStandard):space+dot1",),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we still have commands from previous and next line?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

braille_nextLine and kb_downArrow generally do the same thing, at least by default. If however you tether braille to the review cursor, then braille_nextLine will move the review cursor up and down by line, but I think this is a fairly rare usecase, and certainly none of the braille manufacturers I'm talking with seem to care. In future we could consider some kind of toggle command on the braille display to switch between panning and moving by line or something. But it seems the expectation is that joystick / dpad acts like pressing the arrow keys on the keyboard.

@michaelDCurran michaelDCurran merged commit 5c062dc into master Mar 23, 2023
1 check was pending
@michaelDCurran michaelDCurran deleted the hidBrailleMappingImprovements branch March 23, 2023 21:53
@nvaccessAuto nvaccessAuto added this to the 2023.2 milestone Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants