Draft of ideas 16/17

ideas/index.md

@@ -462,3 +462,90 @@ The corporation to initially develop it will license it for use with their appli
 Even at 10% per ride as an "off the top" for the company creating it could be profitable.
 Not exceedingly profitable, not venture capital and investors profitable,
 but it could support a small team, I'm sure.
+
+## 15. Embedded Accessibility
+
+### 15.1 Embedded Assistive Technology Layer
+
+"Decolonize" GNOME's accessibility structure.
+GNOME has accidentally capped it's assistive technology services by making them absurdly complex to develop for, especially in other languages.
+I can submit my own experience as proof: trying to work with GIR (GNOME Intermediate Representationn) in Rust is a fricken' nightmare.
+This exends to every aspect of the API.
+Why do we have the following types:
+
+* `GArray`
+* `GInt`
+* `GHashMap`
+* `GAccessible`
+
+What we need when it comes to accessibility is *extremely* portable C that can be built on any platform ***even without a standard library***.
+Licence it as LGPL so that "big tech" may benefit if they wish.
+
+Now, we can use:
+
+* `[insert structure here]`
+* `uint_32`
+* `[{char*, char*}]`
+* `struct Accessible`
+
+All of these would be native C types specific to the accessibility interface and without building a large project with Meson and GNU automake.
+
+Dead simple, C99 with native types that can be compiled on any system with a Makefile.
+
+Maybe some bindings for other languages, code generation so that new methods and structures can be defined automatically... But that's far in the future.
+
+### 15.2 Embedded Voice
+
+I know that there are alraedy embedded voice solutions, but is there an open-source (libre) one?
+Is there one that is so bare bones that it can compile on an [Arduino](https://www.arduino.cc/)?
+I bet not.
+
+Sure it might not have all the nice features of, say, speech dispatcher, but it could at least allow easy accessibility for low-power devices like a flip phone.
+It may not seem relivant, flip phones after all are 10 years behind the mainstream, but I answer that with another question: do the blind have the freedom to choose?
+
+No.
+
+They choose what products *have* accessibility features,
+and since accessibility is not requied by law for these consumer devices (after all it's a choice to own a phone at all),
+and since each company needs to develop their own accessibility stack---
+it would appear that freedoms have been limited by this difficulty.
+
+### 15.3 Embedded Screenreader
+
+Finally, if the other two sections are made possible, then we may have a change at a "no std" screenreader.
+It seems far-fetched now, but why not?
+Add-in cards from the 90s could sythisize speech from the text shown in a DOS pronmpt, so why can't we have at least basic voice on every Microwave, TV remote, toaster, and toilet?
+
+My point is not that it is necessary for all these things.
+My points is that right now it's not a choice.
+
+I'm not sure how well something meant to be this simple could scale up to desktop usage,
+but what I can say is that I'm sure it would perform like mad.
+This thing would soar through speech and events.
+It would be so fast that "Big Tech" would be green with envy at the simplicity, embeddability, and performance that the open-source community has created.
+
+Maybe one day they'll want to adopt the standard for themselves?
+Who knows.
+
+My point here is that if the code was written in a far simpler manner,
+and if it was written to not need access to the standard library,
+then maybe, just maybe there's a chance creating something that is lightning fast, easy to interface with, and simple to implment could create a whole new world of accessible tech for the blind.
+
+Imagine if a *tiny* Cortex-M0 was able to process accessibility events the same way at-spi does right now.
+Don't tell me that this wouldn't be a game changer.
+
+Speaking of a game changer...
+
+## 16. Accessible BIOS 2: Electric Boogaloo
+
+What if you could use an embedded screenreader in the BIOS?
+What if you could include it in nearly any BIOS since it's easy to compile and implement for nearly any system?
+What if a baby RISC-V chip were able to receive events over USB-C and use piezo-electrics to have a one-cell braille display on the side of a [Framework](https://frame.work/) laptop?
+
+No we're talking!
+No more need to ask if your computer is on, or if it is still booting; simply have a different letter for each section of the boot process display on the one cell.
+Maybe this would require firmware, who knows.
+
+Dream big, baby!
+Might as well, since we gotta live here either way.
+