Hi and thank you for your amazing response.
OK, let’s cover the ground work lol 
I rely on the mac, also iOS, both use VoiceOver which is a screen reader providing a blind user both keyboard and mouse / trackpad based navigation of the MacOS and any applications which have the accessibility pre-requisites added before release. Navigation with a screen reader like VoiceOver on the mac relies on a series of shortcuts, though the mouse or trackpad can also provide feedback. I use both keyboard and trackpad for a number of functions of VoiceOver.
Navigation of an application is based on how the application is structured, say you have an application in a standard structure format, you have the system menu bar which MacOS relies upon regardless, unlike linux where each menu bar is part of the actual application and not a system tied menu resource, so an app in MacOS would have a window or windows, layers where as an example you may have navigation panes, edit fields, etc, toolbars, etc. Navigating panes, objects, etc is a means of keyboard cursor interactions, function navigation to interact with text, a button, a control element such as a slider or input value source, etc. moving from that you stop interacting with the element (backing out) and then navigate to the other functions you interact with. some principles rely on group mode navigation, quick-nav tools, etc, all depends on how an app behaves.
If something like Aeolus were to be taken in to an accessible pathway as an example, I would recommend a UI based purely on buttons with text label identifiers, so each button would be seen by a screen reader so that the text identifier would state what the button was, it would be important that a screen reader can identify if the button is enabled as in Latch state or just a functional interaction like an "OK or “Cancel” button. so the difference is in definition of function. It would be easy to turn Aeolus in to a spoken system.
Interaction with Aeolus can be achieved from my understanding through 2 clear hardware principles.
1: Console based stop / piston interaction. or custom hardware surface like would be developed by companies such as Yaeltex.
2: Touch Screen environment.
One of the downsides of today’s digital consoles is the use of lit tabs where it’s a touch action but no positive physical difference as to engaged / disengaged, same with some drawstop systems. As a blind organist, working with a pure console which has been electrified, the stops whether tab or draw stops are physically noticed by running the hand over the area or finger to define a raised stop as an active voice, couplers, etc. Digital organs except for some custom builds, don’t offer this. Brands like Allen, Rodgers, etc suffer this design issue on basis of cost. to have an actual electro-mechanical or electro-magnetic (piezo) action for tab stops or draw stops means serious cost.
The advantage of Aeolus as a software based environment would be that a control surface responding to basic midi / sysex or other function command principles, could take custom surfaces. Now, for a blind person, it wouldn’t matter in a tactile sense so much if as a good example if a stop switch had a bulb which would generate a temperature change (not hot but a micro-sensitive reaction of the skin), but also a pure focus on the use of the screen reader, if not the screen reader, then Text To Speech Engine as a program-wide resource where you send the audio of the speech engine to a different output (say the computer’s own speakers / line out) which could then be used by the user to monitor functions pressed, etc this wouldn’t be broadcast to the outputs of aeolus as if this were installed in a church, you don’t want to hear from any main speaker suite “Piston “N” active.” you’d give the congregation a heart attack.
The organnery system seems to be using a debian distro, now I’m not a linux geek, perhaps I should become one lol. In order that Aeolus be able to provide an accessible experience for configuration, voicing, etc, then yes, accessibility is indeed vital. This is where I’ve already emailed Raphael at Organnery to raise this and offer my support, so I can’t say other than that.
For the Mac Port however, It would be a real blessing and advantage if a version of this could be built as a package for the Mac, using the standard developer resources and not JAVA / X11 which would then cause some issues of window object accessibility, in fact JAVA is the worst developer tool for the blind and is part of the dev source for Hauptwerk.
I hope some of this information helps.
Lew
A switch that would vibrate as well, presumably with a LED above.?
