Noticed increased accessibility on the Mac

[mdyde]

Thanks, Lew.

Very best wishes for a speedy recovery from the Christmas injury.

I've made a note in our enhancement request about the tool you mention for future reference.

I know this might sound a bit mad, but how's this for a thought / suggestion.

If direct accessibility to the stops would be a challenge, could we create a set of wizards to allow a user with sight loss to, when prompted, set up a physical console or midi environment to map controls to interface elements?

Say...

Stop jamb Wizard - allows user to map stops to both jambs based on spoken prompts or screen reader navigation of the wizard.
Pistons Wizard - as above, same concept.
Accessories Wizard - as above but for controls like expressions / crescendo pedal, toe studs
Sequencer Wizard - set up navigation buttons, set, gen cancel, etc.

Wizards like this could be implemented as part of the UI without the worry of navigational issues of panes for the visual elements of an organ library.

Another idea would be. I don't know if you remember Growl at all... it used to be a component of MacOS system notifications until we went native. but what if when a stop or piston is pressed, system speech synthesiss engine would announce the stop name and status, as an example "16' Open Wood On" or depending on how many divisions you have, could say instead "Great 16' Open Wood ON" and same status if turned off. features like this could be enabled / disabled within the preferences and add a tab in preferences to set up spoken objects without actually making the main panel based on changing GUI's fully accessible. If the necessary elements of creating wizards that save the state for each organ library as part of the loading file structure, then if you're just relying on a pure console or midi environment and don't want to interact with the host computer all the time, then making spoken stops / pistons / sequencer / accessories available would be the next best option and viable with less intensive elements. the only elements you don't need spoken are expression / crescendo state because that's a purely tactile and sound based observation. something like this could get blind users using hauptwerk before we find the final solution.

VOCR is more of a temporary solution, it can get you out of tight scrapes, but it's not fully reliable, but if you are getting to know voiceover and testing navigation, it's a tool to learn from if anything, it may work better this time around. I had tried it initially in an earlier build with an older version of hauptwerk and it worked to a degree but required so much work to be stable.

lew

[mdyde]

Hello Lew,

Thanks very much for the additional suggestions and thoughts, which I've added to the enhancement request log too, for future consideration.