Api: function to output to braille-displays

[mespotine]

I'm not sure if this already works this way or if it's hard to do, but I would like to ask for a dedicated function to output messages to a connected Braille display, maybe a dedicated one for output to TTS-only as well.

My thought is, that in some cases, splitting messages up into both "output-ways" would be a good idea.

For instance, braille display outputs a help-text for a script to read, while the script outputs via text to speech states like clipping-warnings that you can hear in the background.

I think, a function, that returns the valid characterset for the braille-display (6 point vs 8 point) would also be nice to convert characters into supported ones (unless the drivers already do it automatically...have no braille-display to check this...)

[ScottChesworth]

If this turns out to be possible, I think it's worth pointing out that separating output across screen reader and braille display is only gonna add value for a fairly small subset of users. Braille displays ain't cheap. I'd tread super carefully around this, you'd need to make sure you're not inadvertently placing a barrier to entry (hardware cost) in the way of a solid UX.

[jcsteh]

Right now, it isn't possible anyway. OSARA uses standard APIs to send notifications, rather than screen reader specific APIs. The upside of that is that we don't have to support individual screen readers separately and it's a lot cleaner. The downside is that standard APIs don't differentiate between speech and braille. While I can see use cases for that, there are definitely UX concerns as well as technical concerns. There's also a lot more to braille than just displaying dots; e.g. scrolling, routing, etc.

I'm not ruling out specific braille support in OSARA completely. It would definitely involve some special communication with screen readers, but I've been thinking about a way to cook that up that at least uses standard APIs in such a way that we can avoid screen reader specific hooks within OSARA itself. It's not something i have time to work on at present, though.

[davidkreynolds]

Whilst a Braille user myself, I can see Scott’s point here, aside from which you’ll possibly end up with compatibility issues which could make the development of such a thing at very least, cumbersome.

David.

From: ScottChesworth @.> Sent: 02 November 2022 00:33 To: jcsteh/osara @.> Cc: Subscribed @.***> Subject: Re: [jcsteh/osara] Api: function to output to braille-displays (Issue #805)

If this turns out to be possible, I think it's worth pointing out that separating output across screen reader and braille display is only gonna add value for a fairly small subset of users. Braille displays ain't cheap. I'd tread super carefully around this, you'd need to make sure you're not inadvertently placing a barrier to entry (hardware cost) in the way of a solid UX.

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/805#issuecomment-1299394109 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4CGCGMLJZA5RSDAZNCDHLWGGZFHANCNFSM6AAAAAARUNGD6E . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/AD4CGCEGZGRQQUCINJP26FDWGGZFHA5CNFSM6AAAAAARUNGD6GWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSNOMXD2.gif Message ID: @. @.> >

[ptorpey]

Just as a note, the braille support for JAWS is quite good due to Jim’s JAWS scripts, so there already is some support for braille with Reaper if one is using JAWS.

Also, as Jamie pointed out, just pushing braille messages in a similar manner to how Osara pushes speech messages probably isn’t the answer because there are a lot more factors that go into what is displayed in braille and how it is displayed. There was a lot of work and code that went into the JAWS scripts to make this possible. I’ve also worked with adding braille features to Sonar and Samplitude and can vouch for the fact that it is very different from pushing nuggets of speech output.

Although it is nice to have solutions that are platform agnostic, perhaps someone needs to develop separate solutions for NVDA and Mac’s if those features have enough demand and people interested in putting the development time into what it takes. Unfortunately it isn’t a perfect world out there.

--Pete

From: davidkreynolds @.> Sent: Wednesday, November 2, 2022 5:41 AM To: jcsteh/osara @.> Cc: Subscribed @.***> Subject: Re: [jcsteh/osara] Api: function to output to braille-displays (Issue #805)

Whilst a Braille user myself, I can see Scott’s point here, aside from which you’ll possibly end up with compatibility issues which could make the development of such a thing at very least, cumbersome.

David.

From: ScottChesworth @. <mailto:@.> > Sent: 02 November 2022 00:33 To: jcsteh/osara @. <mailto:@.> > Cc: Subscribed @. <mailto:@.> > Subject: Re: [jcsteh/osara] Api: function to output to braille-displays (Issue #805)

If this turns out to be possible, I think it's worth pointing out that separating output across screen reader and braille display is only gonna add value for a fairly small subset of users. Braille displays ain't cheap. I'd tread super carefully around this, you'd need to make sure you're not inadvertently placing a barrier to entry (hardware cost) in the way of a solid UX.

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/805#issuecomment-1299394109 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4CGCGMLJZA5RSDAZNCDHLWGGZFHANCNFSM6AAAAAARUNGD6E . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/AD4CGCEGZGRQQUCINJP26FDWGGZFHA5CNFSM6AAAAAARUNGD6GWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSNOMXD2.gif Message ID: @. <mailto:@.> @. <mailto:@.> > >

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/805#issuecomment-1300175680 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJLKTEJ6KUVZHDN6AJ3WGJHNHANCNFSM6AAAAAARUNGD6E . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ADEPTJJSM7KX74SDCWOZMCDWGJHNHA5CNFSM6AAAAAARUNGD6GWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSNP4NUA.gif Message ID: @. @.> >

[jcsteh]

Although it is nice to have solutions that are platform agnostic, perhaps someone needs to develop separate solutions for NVDA and Mac’s if those features have enough demand and people interested in putting the development time into what it takes.

Whatever we do here, we're going to need some specific code for NVDA and VoiceOver, probably outside of OSARA. However, I'd ideally like to have OSARA handling most of the work, just interfacing with some other component for the output/input of braille. This way, we get a consistent UX in the long-run, as well as easier implementation because OSARA has access to the entire REAPER API. All of that said, this is all just broad theoretical aspirations at this point with nothing real to back them up. :)

[mespotine]

Ok, from what I see, this would be too much of a hassle for too little benefit, sadly.

One more question: does outputMessage always send to TTS or does it depend on user's setting?

[ScottChesworth]

outputMessage delivers to whichever screen reader is running. That way, messages are delivered with existing user preferences re voice, rate, routing etc all factored in. Dunno whether outputMessage will report through the OS TTS if there's not a screen reader running, but even if it does, it's worth being aware that'd be seen as a less desirable UX by a lot of folk, experienced screen reader users in particular.