OpenMpt accessibility discussion

[GoemonIshikawa]

Hello all, my name is GoemonIshikawa, and I am a fully blind user of OpenMPT who uses the screen reader NVDA
https://www.nvaccess.org/.

I made this topic as well as a video detailling the accessibility of the software and what I can do in it, as well as the things I can't do and what a screen reader is, and what improvements need to be made for further accessibility. I made small samples with OpenMPT and pointed them as well, and if available I will attach them here. The main focus though is a small sample of the Goemon theme from the legend of the mystical ninja although the tempo isn't correct, otherwise i'd vibe all day and the video wouldn't end haha.
https://drive.google.com/file/d/1o0_fNhGQasLk-8dGrgW7pzymTKcGiHOn/view?usp=sharing.


Little bit about me.

Some people know me as The chiptune archiver and on Battle of the bits I'm Juan reina. I have been introduced to OpenMPT about 8 years ago but this was when Openmpt wasn't usable, and what you could access came from an NVDA adon that made certain controls and the pattern view accessible. But since that adon is not worked any more and the main accessibility is in the software, it's my note that some blind people must have made a push to talk and work with the devs for that change. Now that I have an account now I can push for it in my own way, and work with accessibility that will be usable with screen reader.

If you all need anything said that the video doesn't quite say please let me know and I will tell you as much as I can.
My aim is to make music as I can't make music via a DAW, and to eventually make some money to give back financially to OpenMPT, as it's of the only trackers that my people can use.
I've attached the samples I've worked with save for Goemon.mptm as I want to redo it.

[Saga Musix]

Welcome to the OpenMPT community. It's really difficult to find the time to watch through a one-and-a-half hour video to pick up what are potential issues that you want to be fixed, so I would greatly appreciate that you either give a concise summary of those things, or even better, create an issue for each one of them over at https://bugs.openmpt.org/

I got roughly to about 18 minutes in and the only actionable thing I found until then was a list of keyboard shortcuts - which already exists, as part of the manual: https://wiki.openmpt.org/Manual:_Keyboard_Actions - are you not aware of this list or is there something that's missing from it that you would need?
I also only realized through the video that the Expand and Shrink pattern icons don't have shortcut counterparts, so those will be added in the next OpenMPT version.

Edit: Around minute 25, you seem to struggle to go from the visual sample representation (where the keyboard focus resides by default, so that you can audition the sample using your keyboard) to the sample properties. You should use the "Switch between upper / lower view" shortcut (default: Ctrl+Shift+Tab), which will automatically toggle between those two areas. The same shortcut is available in all areas (Global, Patterns, Samples, Instruments, Comments) to switch between the two views each editor area is comprised of.

You're definitely not the first blind OpenMPT user, and thanks to the blind users in our community, we have been able to improve accessibility over the years quite a bit. I wouldn't say that OpenMPT wasn't accessible before 2025 (as you put it in the video), although some basic things did require workaround for many years (essentially because nobody ever told us that they need fixing). Every report about accessibility issues is greatly appreciated and will help making the software better.

[A11CF0]

You should use the "Switch between upper / lower view" shortcut (default: Ctrl+Shift+Tab), which will automatically toggle between those two areas. The same shortcut is available in all areas (Global, Patterns, Samples, Instruments, Comments) to switch between the two views each editor area is comprised of.

This action doesn't seem to have a default shortcut yet. Not even in the latest trunk revision. Having it would really be helpful for new blind users, I think.

[Saga Musix]

Huh, I could have sworn I added that as a default shortcut. I guess not! Would you have a specific preference other than the proposed Ctrl+Shift+Tab?

[A11CF0]

I personally use Ctrl+`, but Ctrl+Shift+Tab is perfectly fine too.

[GoemonIshikawa]

Hey all, I'm sorry this took me so long to get back to this topic, but in the next post I will answer all your posts as well as post to the OpenMPT issue tracker. I don't know how to use it though, so please excuse the mislabeling of issue content.

[Saga Musix]

I personally use Ctrl+`, but Ctrl+Shift+Tab is perfectly fine too.

Ctrl+` would probably not work well as a default shortcut as I'm not sure this would cleanly map to an existing, non-conflicting key on various keyboard layouts. As a default, that is guaranteed to work on pretty much anyone's keyboard, I have no added Ctrl+Shift+Tab.

I don't know how to use it though, so please excuse the mislabeling of issue content.

We all mistakes, that's fine. They can be fixed. The one most important thing is to keep things tidy (one issue per bug - not one overarching accessibility issue) and concise. In the intro text for the issue submission form, there are a number of links to good guides how to write a bug report. If you haven't done this before, I highly recommend reading through at least one of those to get an idea how helpful bug reports look like.

[GoemonIshikawa]

Okay, let's get to posting!


@Saga Musix I'm so sorry the video was too long, yeah I wanted to make it shorter but I had a tun of things coming and it just kept getting bigger and bigger.

What I meant is making an improvement on the keyboard shortcuts as when I tried to use the keyboard shortcuts creator to make new shortcuts, you'll have a problem where you'll be stuck in the creator edit box, and any attempts to move the mouse via emulation with the 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.
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.


For the changing of views Ctrl+Shift+Tab or Ctrl+Tab works too, but as @A11CF0 said the command doesn't work although it's logged in the refs as so.


I did see the keyboard reference thanks for that but I do think that Ctrl+left and rite brakets could be nice ways to expand and shrink patterns.
A bit of off topic but is their any way to expand pattern after the cursor position so you wouldn't have to lose the spacing or select beforehand?


One other issue that comes to mind I need to consult my issues video for full issues, but it is loading instruments via midi banks and libraries. I was speaking with a friend and when I asked him he says he just drags it on to the instrument, but currently they're no ways to utilise instruments from banks, and insert doesn't look to work. I'll need to look more into this though, so I'll let you know my absolute findings via the issue tracker as well as on here if you're like me and this stuff escapes you sometimes.

[GoemonIshikawa]

I have posted the first issue for the keyboard accessibility, If you need any clarity please do let me know, might I ask is this issue good with out markdown? I would put headders but it didn't look like it had any text that would be sutable for it. When I get back up I will check the keyboard creator with a sighted person on latest.

[Saga Musix]

What I meant is making an improvement on the keyboard shortcuts as when I tried to use the keyboard shortcuts creator to make new shortcuts, you'll have a problem where you'll be stuck in the creator edit box, and any attempts to move the mouse via emulation with the 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.

Getting stuck with keyboard assignment shortcut field was fixed almost a year ago. This is really important for reporting bugs - before you report something, please, please, always test it in the latest version. I know it can be frustrating if it means you get stuck somewhere, but it's equally frustrating to read, triage and then unsuccessfully being able to reproduce a reported issue just because it is about something that was already fixed a long time ago. The keyboard settings have been considerably revamped, it's one of the biggest items in the "what's new" blog post for OpenMPT 1.32.01.00. Please do give it a try, it should be a lot easier to navigate now.

For the changing of views Ctrl+Shift+Tab or Ctrl+Tab works too, but as @A11CF0 said the command doesn't work although it's logged in the refs as so.

I implemented it yesterday, and the wiki was updated immediately to document the latest default shortcuts. There will be a new OpenMPT release later today including this shortcut (edit: OpenMPT 1.32.02.00 is out now).

I did see the keyboard reference thanks for that but I do think that Ctrl+left and rite brakets could be nice ways to expand and shrink patterns.

You're free to use whatever shortcuts work best for you, of course. Left/Right brackets are not dedicated keys on many keyboard layout though, so the new default shortcuts were made to be similar to the existing grow/shrink selection shortcuts, which will work on any keyboard layout.

A bit of off topic but is their any way to expand pattern after the cursor position so you wouldn't have to lose the spacing or select beforehand?

If you just want to expand parts of a pattern, draw a selection and use the "grow selection" shortcut. You may have to resize the pattern to an appropriate length before doing so, though.

One other issue that comes to mind I need to consult my issues video for full issues, but it is loading instruments via midi banks and libraries. I was speaking with a friend and when I asked him he says he just drags it on to the instrument, but currently they're no ways to utilise instruments from banks, and insert doesn't look to work. I'll need to look more into this though, so I'll let you know my absolute findings via the issue tracker as well as on here if you're like me and this stuff escapes you sometimes.

It is possible to use the keyboard in place of drag&drop operations, and this is even documented: https://wiki.openmpt.org/Manual:_Tree_View#Common_drag-and-drop_operations

I have posted the first issue for the keyboard accessibility, If you need any clarity please do let me know, might I ask is this issue good with out markdown? I would put headders but it didn't look like it had any text that would be sutable for it. When I get back up I will check the keyboard creator with a sighted person on latest.

Honestly, the formatting doesn't matter all that much, what matters much more is using clear, concise language.

[GoemonIshikawa]

Hello!

@Saga Musix I am very sorry I couldn't test this sooner, but yes you're right the keyboard issues have been fixed, so in this matter I can put a note that'll safely close the issue. Wait how do you all close issues? Sorry I'm just a bit more used to GitHub's layout that this one is going to take some time. GitHub has comments, but you all call it notes.

I still need to look into the midi bank uce issue because either it's not clear or I'm stupid, but I can't figure out how to do it via the manual.

The only problem regarding the keyboard is in certain controls like the keyboard list, where the control state isn't properly respected, for example in the list after the category combo box the list doesn't display the first option unless the user presses down once or twice, so it makes it look like the options aren't before the user.

Now while the issue might not look that bad if the list has multiple options, if a particular category has only one option in its list that option won't be read to user unless the user presses Shift+Tab to go back to the categories, and then presses tab so that the list with one option is shown.

Another example is in the pattern editor if Ctrl+Shift+Tab is pushed to move to the other view with the order list and then via pushing Shift+Tab to move to the pattern toolbar, you'll be able to move rite to a checkbox for example the VU-Meters. If you'll uncheck it via SpaceBar you'll note that you're back in the pattern view, and if you want to rechek the box you'll have to go back to the toolbar to do so.
In this event the controls aren't being properly respected, as checking a box or entering an option shouldn't push you from the pattern controls, as user may want to change other options before properly exiting the controls via the escape key or Ctrl+Shift+Tab.


So that's all I got for now, hopefully I did better this time and I'm much more clearer with things.
In the morning I'll make a final note to the opened issue and figure out how to close it before filing this one or continuing inside it from your response.

If I haven't said it yet thanks for working with me and my people, I am no programmer but I know a little something about programming and UI as well as accessibility structure, but talking is a little more easier than writing, well unless it's about passions like chiptune and trackers and so on.

Oh before I forget! I saw that yall might go cross platform, when that day comes and if you're pushing for tracking on Linux please see if you can contact me, as I have a friend who's the creator of a Linux screen reader and he would also like to work with you! He's actually a programmer so he'll for sure know what he's talking about unlike me haha.

*Edit.*
I did some thinking and it looks like the OpenMPT control state issue is regarding an interface matter rather than a keyboard one, so I have made the choice to file a new issue for that.

[GoemonIshikawa]

I'm trying to close the issue, but I get this message.
"APPLICATION ERROR #24
Resolution "fixed" is not allowed for status "new"."