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