I realize it's not applicable for all games, but would it be feasible to implement screen reader support for PICO-8? I don't know a lot about WAI-ARIA for web or anything about accessibility of standalone applications, so I don't know how such a thing is to be done, but we already have printh() commands sending data to the "@clip"board - adding something like "@tts" (text to speech) seems PICO-8-ish.

PICO-8 already does a lot of accessibility-positive things - the color palette includes a lot of nicely contrasting brightnesses and hues, the controls can already be remapped freely, carts can implement optional mouse and keyboard input - and setting up for speech reader integration would give programmers another way to make their carts playable by everyone.

That sounds like it could be used to circumvent pico8's non-existent support for voice output?
</devil's advocate>

...was there some conversation about PICO-8 voice output I wasn't here for?

Bumping this thread with a thought: there are 128 bytes of GPIO data - that's not much, but it's longer than this sentence. A "poke this address to enable screenreader on GPIO pins" option, with printh(string, "@gpio") using ... idk, 16 CPU cycles per character, slightly more than using ord() and poke() together would cost, wouldn't give PICO-8 any new functionality, but would allow devs to add screenreader support without needing to invent their own Javascript to do it.

Sorry for n00b interjection here. The project by JRJurman shows how you can "externalise" screen reader support - this can also be done locally with printh to a dedicated local file. What if there were simple hooks for "onfocus" in the menu so we knew which menu item was focused, and the state of the menu option? Then the community can do the rest? Or at least it's a start?