View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001903OpenMPTAccessibilitypublic2025-06-29 07:312025-07-02 20:11
ReporterGoemonIshikawa Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product VersionOpenMPT 1.32.01.00 / libopenmpt 0.8.0 (upgrade first) 
Summary0001903: 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.

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

Activities

Saga Musix

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.
GoemonIshikawa

GoemonIshikawa

2025-07-01 17:07

reporter   ~0006409

As I got to testing the matter I can confirm with @Saga Musix that the matter regarding keyboard customisation is resolved, with that being said though some controls within OpenMPT still aren't being respected as they should, though now that I think about it it's more of an interface issue rather than a keyboard matter.

Issue History

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
2025-07-01 17:07 GoemonIshikawa Note Added: 0006409
2025-07-02 20:11 Saga Musix Status new => closed
2025-07-02 20:11 Saga Musix Resolution open => no change required