toggle quoted messageShow quoted text
Please let us know what you find out. I probably don''t have the time to help implement this feature, but I happy to help work on the architecture and design for UEFI accessibility on the edk2 mailing lists, and I can also represent what ever we come up with at the UEFI Spec Work Group.
It would be hard to have a UEFI mandate for accessibility, given there is no guideline on how a User Interface (UI) works. If accessibility requires some from of hardware abstraction, like audio, then we could likely get that into the UEFI Spec. What might be possible is an EDK2 reference implementation of accessibility. Maybe we could use the reference implementation to write a UEFI white paper on design for accessibility? I there is an open source implementation, and an official design guide this would make it much easier for advocacy groups to lobby for this feature.
I've got some experience with accessibility as the macOS EFI OS Loader has a UI for the Full Disk Encryption password. If you press the power button quickly 3 times at the disk encryption password prompt accessibility is enabled and Voice Over gets turned on. You then get localized voice prompts when you move between UI elements. Since this is the OS loader all the resources are stored on the disk. You quickly run into a range of challenges since, audio is hard, abstracting audio is hard (what codec does firmware have to support), Audio files are not small and firmware is size constrained, the need to localize the audio responses causes even more size issues, the boot options are usually written by an OS installer so how would firmware know what to call them?
I listed a lot of reasons it is hard but as Kennedy stated in his "We choose to go to the Moon!" speech sometimes we chose to do things "not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept". If we have a design that means we can break the problem up into smaller parts, and maybe we can find people that have expertise in that part to build a chunk at a time. If we could implement the prototype in OVMF that would show how it works, but run on everyones machines, so that would be really helpful for demos and design review.
On Sep 13, 2019, at 4:16 AM, Rafael Machado <rafaelrodrigues.machado@...> wrote:
I will contact the community you mentioned to get feedback and align expectations.
Hope to hear comments and feedback of other member of discussion (here at EDK2, that is where the work will happen).
Thanks and Regards
Em ter, 10 de set de 2019 às 20:50, Ethin Probst <harlydavidsen@... <mailto:harlydavidsen@...>> escreveu:
I've posted this to the largest forum of blind visually impaired
people I know of to date and have gotten some excellent feedback from
them. I also provided in that post a link to this discussion. However,
I can't possibly forward all their questions onto this group (and I
doubt I can answer them all). If you wish to join the discussion over
there, its over at https://forum.audiogames.net/post/461041/#p461041.
(If we can find a way to merge the two discussions, that would make
everything easier. If we can't, I'm fine with that.)
On 9/10/19, Rafael Machado <rafaelrodrigues.machado@... <mailto:rafaelrodrigues.machado@...>> wrote:
Hi Ethin and all
As Leif mentioned, my mastering thesys was the implementation of a
reference code so a driver for audio at pre-OS would be possible,
eliminating the first barrier for the creation of a screen reader at UEFI,
that is the lack of audio drivers.
My project was based on Intel High Definition Audio, so it is not a generic
code that would fit at all scenarios, but it a first step.
The idea was to proceed this work using the Google Summer of Code
initiative,and I will try my best to make this happen in future editions of
Unfortunately my thesys was written in portuguese, because there was almost
nothing related to BIOS in Portuguese, so the decision was to write in
Portuguese to help the community to attract brasilian developers. As soon
as I find some slot, I'll translate to english.
But you are not alone. Just in Brazil I discovered around 30 blind
developers that area waiting for accessibility at BIOS. Also had some
contacts from US and Ireland.
So it is a market to be explored. Everyone will win.
The companies, because they will attract more people and their families,
and the ones who need accessibility.
By the way, most of the population will need accessible solutions if they
live enough. This includes the uefi community members, that today do not
have special needs, but that may require it in future.
Accessibility is not a wast of money.
This ia what I would like to show to the UEFI community.
Hope to have the opportunity to present this in some future event.
Since this discussion was started, who knows what are the next steps?
My code is available at github if someone gets interested (ps.: The code
has failures. It was just a Prof of Concept)
Lets keep the discussion, because it is important.
Thanks and Regards
Rafael R. Machado
Em ter, 10 de set de 2019 17:00, Ethin Probst <harlydavidsen@... <mailto:harlydavidsen@...>>
Woops, I just realized while reading my message after I'd sent it that
I had linked to the wrong document. The priority system is outlined
over here (https://freebsoft.org/doc/speechd/ssip.html#Top). This
document discusses SsIP -- the Speech Synthesis Interface Protocol.
On 9/10/19, Ethin Probst <harlydavidsen@... <mailto:harlydavidsen@...>> wrote:
While conquering refreshable braille displays would be nice, I thinkhttps://docs.microsoft.com/en-us/cortana/skills/speech-synthesis-markup-language
we should take it in stages. (Some blind people would want this in
along with the accessibility subsystems, however I do not believe that
would be the wisest approach.) Instead, I think we should do what you
suggest: implement protocols for communicating with audio devices
(both input and output) and add audio hooks for the HII. (We could
even make those audio hooks just general hooks/events instead of
partitioning them for a particular purpose.)
You mentioned that not all devices 'have a keyboard'. This is most
definitely true, but not all devices have audio outputs and/or inputs
either. Therefore, if we can't mandate it for *all* devices, perhaps
we could only mandate it (or at least somehow infer it as a
requirement) for devices that both have an interaction mechanism (any
form of interacting with the system directly via the HII and not, say,
over the wire, because that would be superfluous) and have
mechanisms/devices/drivers/... for audio output at minimum. (Audio
input is not necessarily something that is required unless the device
is controlled primarily by voice, but I think having voice controls is
a bit beyond the UEFI specification and is not something UEFI should
worry about. Voice control is not something you should have in the
preboot environment anyway, correct?)
So, I think the first stage we should work on should include:
- Implementing protocols for communicating with audio outputs (don't
worry about inputs right now)
- Implementing protocols/hooks/events that can be intercepted in the
HII by a foreground/background UEFI driver/application
- Implementing some kind of method to allow the accessibility
protocols to read what is drawn to the text when navigating around
The third item -- when implemented properly -- will prevent the
accessibility subsystem from reading everything on the screen every
time the "cursor" moves. Perhaps another good idea would be to
implement some kind of priority system for text-to-speech, like speech
On 9/10/19, Leif Lindholm <leif.lindholm@... <mailto:leif.lindholm@...>> wrote:
Apologies for the delay in responding - I personally don't tend to
read the RFC list (and I know that applies to some other developers
who have now subscribed).
On Sun, Aug 11, 2019 at 06:15:18PM -0700, Ethin Probst wrote:
I'm new here, and was recommended to the TianoCore project by
someone over at the UEFI forum. I've run across TianoCore before,
and like the project.
Before anyone gets worried by the subject line, no, this is not any
kind of legal thing. Its just something I believe needs to
Back in 2016-2017 I contacted the UEFI forum about two problems, one
of which was the format of the spec, which I figured out on my
own. The other problem was not so easily dealt with. Te other
problem relates to accessibility of UEFI-compliant systems and
platform firmware to persons with disabilities. As it currently
stands, such a thing is nonexistent. To be fair, I completely
understand the difficulty that such a thing would require, and I
would fully agree if we still used the PC-AT BIOS systems -- yes,
indeed, I would never suggest this kind of thing on such a system
given that there was no actual standard of any kind for
BIOSes. However, now that UEFI is here, we have such a possibility.
As it currently stands, people with low vision or blind people have
access to their computers in the general sense (I am blind
myself). We can do pretty much anything anyone else could do. We can
code, play games, all that. There are few things that we cannot
do. One of those things is managing our systems firmware in the
As it stands now, I can only boot other OSes or disks via
memorization. While that worked on BIOS machines (I have, or had, an
old Toshiba laptop that was BIOS-based), it no longer works because
UEFI is mercurial. When I access the boot menu now, I play a game of
chance. If the cards are in my favor, the OS I want to boot boots,
and I can go on my way. But if the cards aren't in my favor, I end
up making something happen that was unintended, and, worst of all, I
have no idea what I did.
However, the boot menu is only one portion of a platform firmware
UI. What about the setup utility or other utilities offered by
computer manufacturers? What about diagnostic utilities,
bootloaders, etc? What do I do with those? Well, I only have one
option -- sited assistance. If I go into my computers setup utility,
I cannot trust myself and say to myself, "OK, I know what I'm
doing. All I need to do is change x and save and quit." No, I can't
do that, because memorizing such a complex interface is extremely
difficult, and its something I wouldn't expect anyone to do.
My proposal is simple, and I'm posting it here because I'd likeSo, first of all, I need to point out that what you suggest would be
comments and feedback before it actually gets implemented (it will
take a lot of time, I'm sure): mandate, in the UEFI specification,
that accessibility features for persons with disabilities must be
implemented and documented, and, if such features are not
implemented, then that vendor is not compliant with the
specification. Place strict minimum requirements for what the
accessibility features should do and how they should work.
very difficult for the UEFI Forum to mandate. *But* I don't think this
needs to be a problem.
UEFI primarily exists as a means through which interoperability can be
guaranteed. This means it does not tend to so much mandate what is
actually implemented in a platform, as it defines how it behaves if it
is. This is not 100% true, but suffice to say that mandating the
functionality you are asking for *without* having a reference
implementation available would likely simply be ignored.
If you want to turn thumbscrews, get Microsoft to add the requirement
to their windows logo requirements :)
However, as much as it is difficult to force people to develop this
support, if a functional reference implementation was published under
a permissive open source license, it would take a pretty spectacularly
incompetent product owner not to incorporate it in their products.
Now, I'm sure someone out there will ask me how this can beI have added Rafael Machado on cc. He did a PhD on firmware
done. Well, that's why I've joined the group -- though as I
familiarize myself with EDK2 development and all that I may actually
be able to participate as more than just an accessibility expert, of
accessibility, including a prototype implementing an audio driver for
EDK2. The resulting thesis can be found at
As a side note, I have been blind all my life. I was born with
retinopathy of prematurity (ROP), which resulted because I was born
at 26 weeks. My retina was detached, and, though the doctors
attempted to fix it, it would not remain attached, and there is no
chance of it getting fixed now. I would neither want nor care for
such a cure, however. I have lived my entire life blind, and while
the thought of gaining site back is appealing, I am unwilling to go
through the years and years of rewiring and reconditioning of my
brain that would be required for me to survive with site. To me, it
is simply not worth the cost.
But back to the discussion at hand: I would be happy to discuss howYes, I agree, operating systems are already doing their things.
the accessibility features would work and what would be
required. Even standardizing, through the specification, a key
combination to toggle the accessibility features would be nice, as
that would alleviate the major problem of a blind person buying a
new computer and not knowing how to enable the accessibility
features. The overarching goal would be to make the preboot
environment (including applications run within it) accessible and
usable by blind and visually impaired people as a boot service
Again, mandating such a key combination is not necessarily something
that the UEFI specification can do. Some devices won't necessarily
have a keyboard.
Some things the UEFI specification could do is:
- Add protocols for Audio output (and possibly input) and talking to
- Add audio hooks for the Human Interaction Interface subsystem (HII).
EDK2 could then start adding device drivers producing these protocols,
and enable the support for some reference platforms.
Would we need any specific support for things like refreshable braille
It would be superfluous to make this a runtime service, as allAgreed.
major OSes already have accessibility features. Plus, managing such
a thing would be impossible to do.
This email has gotten quite long, so I will suspend the discussionBest Regards,
of functionality and how I would like it to work for a future email
once everyone has gotten on board.
Thank you for your time and consideration.
Ethin D. Probst
Ethin D. Probst
Ethin D. Probst