New user to OpenMPT who is blind

[Saga Musix]

You can find a full list of supported opcodes at https://wiki.openmpt.org/Manual:_SFZ_Implementation - it's by far not complete but certainly a bit more than just key information.

[sethmhur]

How do I send a om focus update and how do I get the latest verson to test out this new property found in the wiki?

[Saga Musix]

The link to the latest test version has been provided on page 1 of this thread: It's https://builds.openmpt.org/
For how to send focus messages to an application, you will either have to consult the manual of your screen reader or wait for the other users to help you out.

[Diamond]

Diamond: Do you think it would be worthwile to have a wiki page with tips and tricks for visually impaired and blind users? It could also be included in the manual that way.

Indeed that would definitely be useful.  I'll contribute as time allows.  I've been a bit under the weather and I may have to return to the hospital for a possibly recurring blood infection.

I did play around with the "AccessibilityFormat" item you added in "Advanced" settings.  The format for the string was not difficult to figure out.  Very useful.  Thanks again for adding this.

[Diamond]

I'm of the opinion that Jaws support is a lot of extra trouble since it doesn't respond as well to MSAA, though it does to some extent.

Unfortunately, I have to disagree with this opinion.  Despite any issues JAWS may have with MSAA which I cannot personally verify, it is still likely the most widely used screen reader so support for it should not be casually dismissed.  I respect NVDA's capabilities and I'm sure it is quickly becoming a close second, but there are many users including myself who still prefer JAWS.

One thing not yet mentioned: the sample mapping dialog is really difficult with a screen reader.  I've sort of figured it out but it isn't possible to do things with the keyboard directly, so I have to use the mouse simulation functions of my screen reader to click on things.

Placing focus in the sample mapping section requires virtual cursor/mouse functionality of your screen reader, but once it does have focus, you can assign starting note with the keyboard and sample assignment with the numeric keypad.

Last but not least... maybe this'll help devs of Famitracker and other trackers which have extensive keyboard navigation already to implement screen reader support?

Part of the problem is that unlike OpenMPT, most other trackers do not use standard Windows controls.  This makes accessibility more difficult to implement and probably means developers will have less incentive to even try.

[Diamond]

How do I send a om focus update?

Unfortunately, this requires a bit of scripting knowledge.  With JAWS for example, you could create a script for OpenMPT and assign it the shortcuts Insert+Tab and CapsLock+Tab for the laptop keyboard layout to override the standard behavior of the "Say Window Prompt in Text" command.  The script would look like the following:

Script SpeakPosition ()

If GetMenuMode () == inactive Then

SendMessage (GetForegroundWindow(), 0x07, 0, 0)

EndIf

EndScript



It doesn't work perfectly, but it at least updates the buffer which JAWS will not do in OpenMPT for some reason.  I personally use a combination of JAWS scripting and AutoHotkey that works well enough for me, but which I won't share because it isn't completely reliable.



With NVDA, I suspect you would have to create a custom add-on to use SendMessage functionality assuming it is supported.  NVDA add-ons are written in Python so I suspect the functionality is probably there.

[Diamond]

Interesting, I just tested with NVDA and it doesn't speak notes and sample numbers while navigating the sample map.  Yet another reason not to so casually dismiss JAWS.  Each screen reader has it's strengths and weaknesses so it's good to have more than one installed, but JAWS definitely still has some advanced functionality that NVDA does not.

[musicalman]

Despite any issues JAWS may have with MSAA which I cannot personally verify, it is still likely the most widely used screen reader so support for it should not be casually dismissed.

*sigh* I dont' want to turn this into a screen reader debate. But I really do have to stand my point. Firstly I won't say you're wrong, because you're not; Jaws is still the most popular and dismissing it would indeed be an inconvenience to many people. But the reason I said what I said is severalfold. Because Jaws is changing, some programs that used to support it no longer do. One example is the popular Blastbay Game Toolkit, I know it's completely unrelated to this topic, but nonetheless a popular tool. Jaws support has been dead for years (see below for why). Osara, while it works with Jaws, is clunky (just tested). It feels like both are competing for who gets keystrokes because Jaws will say blank often before doing anything, and has a very irritating lag any time you press an Osara command. NVDA and Narator do not do this, and as a result your productivity increases. You mentioning how Jaws does not update the window focus with insert tab and having to implement workarounds is another example. While there are valid reasons for why it behaves that way, I don't have the patience to work around it when I can just fire up another screen reader which will be faster with this task. However, Jaws might work better in the sample mapping dialog, which I was going to ask you about since I'm not sure how to use it with the keyboard. So maybe that will persuade me to persevere the Jaws root or learn how to do it with NvDA once I've learned what Jaws is doing. Or, I may just use the oncoming sFZ support for that purpose. It really all depends on what you have more patience for I suppose, but my point wasn't to casually dismiss Jaws. It was simply to point out that fluid Jaws support takes extra work it seems for various reasons. Developers aren't always willing or able to do that extra work, considering Jaws's complexity and price tag, especially when other free screen readers exist that really are good alternatives and are easier to cooperate with. Again I am not trying to say Jaws support isn't worth the cause, but only to point out the reasons why other screen readers are easier to work with in this regard so Jaws often gets set to the side in those cases.

[Diamond]

*sigh* I dont' want to turn this into a screen reader debate. But I really do have to stand my point.

Sigh indeed.  My intention was never to turn this into a screen reader debate.  In fact, I specifically stated that each screen reader has it's strengths and weaknesses.  Although I don't believe JAWS not updating it's buffer in the "Patterns" tab is any kind of example of deficiency on behalf of JAWS considering that it is far from a control designed for accessibility.  The pattern control is bitmapped and even NVDA speaks extraneous information when using it's equivalent of the "Say Window Prompt in Text" command.

[musicalman]

Well, if we agree not to debate, it's settled. Was just trying to be helpful based on my own experiences with the applications I mentioned above.

[Diamond]

Agreed.  Although it is worth keeping in mind that personal experiences can vary widely depending on the software being used.  I could never use Virtual DJ with NVDA due to it's lack of support for custom highlights.  I could never use WinBuilder with NVDA due to it's lack of support for application graphics.  And so on, and so on.

[musicalman]

I'm still very interested to know how you use the sample mapping dialog with Jaws, but I don't think I've explored it properly either. What I remember doing back when I was trying it was selecting the sample from the list that I wanted to assign to keys, and then mousing around on the onscreen keyboard and clicking on the keys I wanted that sample assigned to. It wasn't very nice to be sure. I did actually use Jaws to do it at first, though I think I figured out how to do it with NVDA and screen review. I never really figured out what Jaws and NVDA did and didn't read. I didn't even know the numpad was useful in that dialog since I was using the numpad for screen reader keystrokes.Sorry if I sound vague or inaccurate, this was last year some time and my memory of this is fuzzy.

[Diamond]

This is somewhat difficult to explain and there may be some points I'm missing from a visual prospective, but I will do my best.  By default, an instrument has all notes assigned to it's equivalent sample number.  Instrument 1 has all notes assigned to sample 1, instrument 2 has all notes assigned to sample 2, and so on.  When the sample map has focus, there are 3 columns.  The original note, the currently assigned note, and the currently assigned sample.  Again by default all assigned notes are the same as the original note.  JAWS only reads the last 2 and unfortunately it speaks them both as a single unit, no matter which column is selected.  So for example, JAWS might say,
"C-5, 2"
C-5 being the currently assigned note and 2 being the currently assigned sample.  The Left/Right Arrow keys switch focus between the assigned note and assigned sample columns.  The Up/Down Arrow keys switch to the next/previous note/sample pair in the map.  Although when the assigned note or assigned sample columns have focus, the Left/Right Arrow keys will just advance to the next/previous note/sample pair in the map as well.  When the assigned note column has focus, you can press a note on the keyboard to change it.  When the assigned sample column has focus, you can type a sample number on the numeric keypad to change it.  For example, 03, 09, 17, etcetera.  Typing 00 will assign the selected note to no sample.  Of course, NumLock has to be on for this to work.  Hopefully this will help, but I don't think I can explain it any better.  If you think they might be useful to study, I can upload a couple of drum sample maps I have personally created.

[Saga Musix]

I'm not sure if you both talk about the same thing - musicalman mentioned the sample mapping dialog, which is separate from the sample map the instrument view. I think the sample mapping dialog is completely unusable without the mouse (even setting sample assocations requires the mouse there), but the sample mapping table that is found directly on the instrument tab definitely should be more accessible, since it is keyboard-driven, as Diamond explained. Its downside is that you need to memorize which sample is which, because (even for sighted users) there is no way to see which sample number belongs to which sample name.

By the way, I don't think it's bad to have a little debate here - in particular since the results of it could be part of the wiki article on accessibility.

Indeed that would definitely be useful.  I'll contribute as time allows.  I've been a bit under the weather and I may have to return to the hospital for a possibly recurring blood infection.

Ah, sorry to hear that. I don't want to start a page when I personally have not much to contribute, but if you want to write something up, I suggest to put it on this currently empty page: https://wiki.openmpt.org/Manual:_Accessibility

Although I don't believe JAWS not updating it's buffer in the "Patterns" tab is any kind of example of deficiency on behalf of JAWS considering that it is far from a control designed for accessibility.

I cannot be sure about this but it does sound like a bug to me (or rather overzealous optimization) that Jaws caches the old text, so it might be worth reporting a bug to the developers.

[Diamond]

I'm not sure if you both talk about the same thing - musicalman mentioned the sample mapping dialog, which is separate from the sample map the instrument view.

Ah yes, I vaguely remember that dialog.  I didn't think of it initially because I also remember it being mostly keyboard inaccessible so I never use it.  So, does the sample mapping dialog do the same thing as the sample map on the "Instruments" tab or do they serve different purposes?

I cannot be sure about this but it does sound like a bug to me (or rather overzealous optimization) that Jaws caches the old text, so it might be worth reporting a bug to the developers.

Perhaps, but I still think it is more likely that JAWS is simply having problems accounting for a control/element to which it is not accustomed since the command works correctly in other applications.  Also, reporting it as a bug probably wouldn't do much good since most screen reader developers will only spend time and effort investigating issues which affect popular/commonly used applications.