But, again, Kyle, the serial console is also kernel dependent. You're
simply depending on a different set of developers. You could switch to a
user space screen reader once the host is done booting just as you
switch to a getty once the boot is done.
-- John Heim
On 04/26/2017 04:52 PM, Linux for blind general discussion wrote:
Tony and all,
I myself am completely opposed to a screen reader being locked into a
kernel, and have been for many years, for very good, technical,
non-political reasons. Text mode is exactly this: text mode. The
layout of the entire screen is available as plain text and some other
character codes that affect colors and other things, all of which are
easy to interpret by a userspace screen reader. This is the nature of
the beast on all operating systems, no matter the kernel. The screen
reader *must* be fully in userspace, and must be modular enough to
handle slightly different input/output interfaces, because that makes
it portable to things like BSD, GNU/Herd or any other new OS that may
come alon, and all with at most the help of a small module that knows
how to read the text that is to be output to the screen, which can
then be sent out to a speech synthesizer, whether hardware or
software, in an equally modular way. Additionally, having a screen
reader in userspace and not bound to the kernel means that no one has
to patch the kernel to accept the screen reader, and screen reader
developers don't have to answer to kernel developers, kernel coding
conventions or kernel release cycles in order to continue development
of the screen reader. Best of all, though a single bug that goes
uncaught in a kernel-bound screen reader has the potential to crash
the entire kernel, a userspace screen reader's bugs only affect that
application, and in the worst cases, the screen reader may need to be
restarted. No bug in a userspace screen reader will cause the report
you've put valuable hours into to get lost in cyberspace because a
previously hidden bug in the screen reader crashed the kernel before
the report could be saved.
I did also mention the serial console as an alternative to a
kernel-bound screen reader. The whole reason I mentioned this at all
is not just because I can make a Raspberry Pi or even a less expensive
computer act as a screen reader, but because I not only receive kernel
boot and shutdown messages, but I receive boot loader messages as
well, which the kernel is unable to provide. This allows me to debug
things that happen when the kernel fails to boot. This can be caused
by any number of kernel related problems, but can also be caused by
filesystem corruption and other things that the boot loader can detect
and report more easily than the kernel that is failing to boot. The
only time I would have a problem using the serial console method is if
the boot loader itself is either corrupt or has no serial i/o, and
thankfully, most do.
You're absolutely right: YASR is not a viable userspace screen reader.
In fact, it's not a screen reader. Rather, it's a shell reader. There
was in fact a try at adding a separate program that could read the
login screen, but the overall nature of YASR makes it less than ideal,
as you still have to run a separate instance of YASR along with the
shell in every terminal you want to read.
Finally, I will reiterate the fact that just because Speakup is not
included in a vendor or distro kernel does not indicate in any way
that the vendor or distro developers don't care about accessibility,
any more than failing to include the alsa front-end utilities would
mean that a distro's developers don't care about sound. Speakup is
just one possible option, and because it for a long time required a
patched kernel, and now still requires staging to be enabled in order
for it to work, has technical limitations that force distro developers
and vendors to make hard choices about whether or not to include such
an unknown variable into the functionality of the kernel, which by
definition is to be a direct interface to the hardware rather than a
way to run userspace programs in kernel memory. Furthermore, there is
a huge difference between not caring at all about accessibility and
not knowing how best to handle it within the framework of an operating
system, especially with such technical limitations as a kernel-bound
screen reader presents. I have said this many times, and will continue
to do so. Instead of complaining about how little you think a
developer or a group of developers cares about accessibility, work
toward fixing the inherent problems with the accessibility tools and
the technical limitations they present. At least give distro
developers enough information to try to help fix the problems rather
than just pissing and moaning on lists like this one when something
you like presents challenges to developers that they otherwise may not
know the best way to take on.
~Kyle
_______________________________________________
Blinux-list mailing list
Blinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
_______________________________________________
Blinux-list mailing list
Blinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/blinux-list
