for hp users, this might not be available to us, because I dont think hp would eeven con it for a second, hp does not eeven update their b450 motherboards to support amd ryzen fifth gen, so why would they do it for aksessibility, hp is kinda stupid with this that they dont update their bios to support new stuf

@29, yeah, I understand.

@31
Espeak's license forces any software incorporating it to be open source.  Chip vendors are likely not going to want to open source their UEFI, unless I don't understand how that market works.  If we want this we need to be able to just hand vendors a screen reader without additional legal burdens.

I am very, very sorry for doing this, but I really want to know, what happened to this? what's the progress?

@35 Read through the entire topic. Your question has been answered a few times already.

@Ethin Hey; I was wondering if I could reach out to you about a semi-related topic, because I had a few questions about software accessibility development. Is it OK if I reach out over Discord? Think I still have you on there but I can't remember your username. I'd know it if I saw it, but I can't remember it off the top of my head.

@37, I understand. I hope it takes off in the near future..
on anoher note, I am using supernova to read this post and tuype it. it's really slow. I don't know how people could use this... oh well, back to nvda I go

@41 I got it, will reply shortly

@43, we can't really do that. Particularly not for UEFI applications.

@45, right, nothing else will work. Though UEFI makes available variables, which are kind of like environment variables, the ones that are specified within the UEFI specification are already editable on Linux. But the specification allows for vendors to expose their own variables. There's no way to write a program to modify firmware configuration because every vendor does things differently, and it would need to be an industry-wide collaboration to get anywhere. Editing firmware memory is also not an option: both UEFI and BIOS store data in multiple places (e.g.: BIOS stores its configuration on the CMOS, and UEFI stores its data in NVRAM and probably other hardware). Most of that hardware isn't even accessible to the kernel, and that hardware that is is locked so the kernel can't modify it anyway without resetting the system first. Take for example the configuration for Intel/AMD virtualization. This configuration is actually stored on the CPU every time the system boots, in what is known as a model-specific register, or MSR. I'll try and avoid going into extremely technical detail, but the processor contains two instructions to modify these MSRs, both of which can only be executed by firmware, operating system kernels, and the like. The particular MSR that controls virtualization features has what is known as a lock bit. When the firmware sets the new virtualization configuration, it also sets this lock bit, which prohibits modification of that MSR until the system is restarted. If the kernel, or anything else, attempts to modify that MSR, the processor will throw an error your way (on Linux, you'll receive this as a signal). You can read the MSR to determine the configuration if the OS exposes that functionality or you manage to run kernel level code, but modifying it is out of the question. Not all firmware sets this lock bit, but 99 percent of the time its set. So as you can tell, firmware configuration is far more complicated than "lets just write a Windows/Mac/Linux program to change it". A lot more happens that you just don't see, and most of that is locked or otherwise inaccessible to anything but the firmware.
You might ask, "Well, why can't we just modify the firmware configuration?" And again, that question has already been answered: there's no way to determine what to modify, or even where it is. If I change a variable that your firmware exposes, I have no idea what that change will do, and manufacturers don't exactly document that because 99 percent of people aren't going to hack the firmware to figure out how it works. Its like asking me to write a program to change your computers environment variables in a nice, friendly way, with descriptions and all: there's no way to know what environment variable does what, and so the only ones that this hypothetical program could change would be those that are documented. All the others would need to be documented first, and since any program can set environment variables, that's just never happening. The only difference between environment variables and firmware variables is that its the vendor of your computer who's doing the variable setup. I won't ramble on and tell you how all of this works, since I doubt most of you are interested in that, though if you are you can PM me and we can talk more about it. But yeah, nothing but firmware-level accessibility is going to work and give you the ability to tinker with your system configuration, because only the firmware can give you that kind of access. Some vendors have written programs that you can run on, say, Windows, but those are vendor-specific and there's no way to make a universal tool.

@47, your thinking of efibootmgr and efivar. There's also /dev/cpu/cpunum/msr, but you don't want to mess with that unless you know what your doing because you could easily crash your system or otherwise make it unstable (or cause all kinds of other weirdness). Thankfully you have to access that file as root, but even still, to my knowledge Linux (and maybe the BSDs) are the only OSes that let you access potentially dangerous functions like that openly.