thinking about Uxn development and assistive technology interfaces
what would it take to make Uxn accessible to people who use screen readers? would it seriously limit what roms people could make?
@tindall that's an interesting question.
From a developer perspective, forth-likes are pretty great since they rely on dictionaries and are space-separated.
From a user perspective, I haven't seen many interesting experiments in that direction beyond ui-to-speech.
@neauoire yeah, from the dev side i'm not hugely concerned, and having support for the themes ecosystem is great because people can set their contrast however they want
i'm mostly interested because i want to do uxn productivity software - like personal inventory management and journalling and stuff - and since it's mostly text based, it'd be nice to connect to assistive tech apis in the OS somehow. maybe through serial out?
@tindall I'm pretty much building this whole thing so when I start to go blind and loose an arm sailing, I can still do my random musings, so I'm interested in exploring that space too.
It doesn't have to be text based tho, actually uxn doesn't even support text natively.. Uxn has EXCELLENT real-time I/O that piggybacks on the host's unix system, so inputing from ass. devices and piping to festival or other ass. tech is not too hard.
@neauoire right, not supporting text natively is kind of what i'm worried about; small amount of screen real estate coupled with not (by default) having an easy way to change fonts by the user means that visual issues will be exacerbated
but, yeah, should be pretty easy to write a little shim program that connects things up correctly
@tindall The UxnVM space is not where these sorts of things should be built, but at the operating system layer.
@neauoire totally - but the uxn rom has to contain all necessary assistive technology annotations and information. that's really my question - it's a lot of extra text to throw around, plus you generally need a tree representation to make it useful (at least for the implementations I know of) which means more complexity and more ram.
@tindall you'd need to stream a lot of resources and data, Uxn is probably not the right environment for doing complex interfaces with nested menus.
@tindall but building something like a calculator, calendar, spreadsheet, text editor, etc.. to be accessible entirely through acc. I/O is within the real of possible.
@tindall This has been on my mind too.
Each ROM being self-contained is nice because it (ideally) pushes each developer to become educated in accessibility. On the other hand, if the uxn culture doesn't encourage that, having an OS that builds in those features is the next best thing..