0001903: Defining keyboard commands in OpenMPT - OpenMPT Issue Tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0001903	OpenMPT	Accessibility	public	2025-06-29 07:31	2025-06-29 15:04

Reporter	GoemonIshikawa	Assigned To
Priority	normal	Severity	major	Reproducibility	always
Status	new	Resolution	open
Product Version	OpenMPT 1.32.01.00 / libopenmpt 0.8.0 (upgrade first)

Summary	0001903: Defining keyboard commands in OpenMPT
Description	Users with screen readers such as NVDA have a hard time making or changing the keyboard commands for OpenMPT, and if the users wish to do so, you'll have a problem where you'll be stuck in the creator edit box, and any attempts to press okay via keyboard will enter a shortcut instead. This is because locally the program expects you to push okay with the mouse but for screen readers we have no accurate control to focus okay or any options in the controls. This was in older OpenMPT versions and I would test latest version to check but I don't feel like getting stuck especially as I have no sighted person to help at the moment. I'll check later though.
Steps To Reproduce	What will work though is if this bug exists upon directing to the edit box the field will record everything save for the direct contact of the control, so if you press Tab to go to the set shortcut edit box, your screen reader will say "enter a command for this action edit blank." note how the tab action isn't recorded? but if I press the Tab key in that edit box then in the keyboard list it'll be recorded as Tab. but if this is in effect we'll still have the problem of blind users not being able to get out of the edit box after assigning the command. My solute for this is to auto jump to the okay button after official record of the command, or either the keyboard list or the category combo box. This way they'll be allowed to push Enter for okay or Escape to cancel and also review choices if anything.
Additional Information	This information regards the NVDA screen reader for Windows but it'll also work with other screen readers, as the information is most important to the state of the control. The control state isn't expecting to do anything after entering of the command nor the beginning of said command.
Tags	No tags attached.

Has the bug occurred in previous versions?	yes
Tested code revision (in case you know it)	N/a

Saga Musix 2025-06-29 15:04 administrator ~0006407	From my understanding (as mentioned in the forum thread), this was not actually tested against OpenMPT 1.32 (as indicated in the table above). The keyboard configuration should be completely usable with only a keyboard as of OpenMPT 1.31.11.00, and another big revamp of the configuration dialog in OpenMPT 1.32 made the structure more clear. Please confirm that you have tested this with OpenMPT 1.32, and if so, please clarify the problem because I cannot see any particular issues with keyboard navigation in the latest version.

Date Modified	Username	Field	Change
2025-06-29 07:31	GoemonIshikawa	New Issue
2025-06-29 07:34	GoemonIshikawa	Summary	This issue aims to rework the keyboard creator, but can be promptly rejected if the issue no longer exists. => Defining keyboard commands in OpenMPT
2025-06-29 15:04	Saga Musix	Note Added: 0006407