Contributed by marco on from the dept.
The free unix-alikes have done a little to support these enthusiastic users. The best attempts have come from the Linux and Emacs communities, with the various BSDs having paid little to no attention whatsoever. Hopefully, this is due to a lack of awareness.
Though there is a fair variety of text-to-speech screen-readers for Linux, few have been ported to the BSDs, and none of them to OpenBSD. Some of them simply aren't portable, some have restrictive licenses, still others are just so poorly written they'd make an OpenBSD developer cry tears.
So, what can we do to be more welcoming to our fellow enthusiasts? I think that porting and cleaning up what Linux has would be a good start. But screenreaders themselves don't offer much more than the ability to tinker with a new OS, which they can already do through a terminal session from Windows or OS X.
Better that the OS itself becomes (optionally) speech or braille enabled, so that the user is provided with the most important feature: autonomy. Without enabling the OS at the lowest level, the user lacks the ability to install it himself, to see the boot prompt, to know when he's been dropped into fsck or ddb. And he can't call up tech support or a friend; a sighted person must come to his location and read the display.
I've been told a good start would be to provide live CDs, pre-loaded and accessible, that they can carry anywhere. A better way is to provide kernel support for braille displays and speech synthesizers. Well, it takes a downward turn here -- these devices are extremely expensive. Braille displays can range from 4-11k USD in price. Ouch. Speech synthesizers are a little more affordable, with the popular DECTalk running around 1100 USD. It shouldn't be too hard to get some of those into the hands of a few who might enjoy writing a driver or custom kernel to support them. The real, and more interesting challenge is to do it all in free software and with everyday hardware.
Hell, I might even give it a go. :-)
Why not offer a clean, reliable UNIX to those who appreciate it for all the same reasons that we do? How's this for credibility, blind users adore ed(1), and at least one uses OpenBSD/vax. How many sighted UNIX users are that hardcore?
[ Note, OpenBSD does have a brltty port. See comments below. ]
(Comments are closed)
By Noryungi (212.11.9.139) n o r y u n g i @ y a h o o . c o m on
Hmmm... I have done quite a lot of free technical support, both for a friend who is blind and for a non-profit association that actually aimed at providing techical information to blind users.
Once thing to keep in mind is that most solutions for Windows (you mentioned JAWS) are a complete nightmare. They are extremely expensive, very poorly designed, annoying, frustrating and totally unreliable. And I am trying to stay polite in what is a public forum...
But another thing to keep in mind is that a lot of blind users (at least in my neck of the woods) also prefer to use 'smart' Braille terminals (see here for a few examples) to access their machines. If they use that solution, a null-modem cable is the only thing they need to use an OpenBSD machine. Since good ol' DEC was, AFAIK, a pioneer in Braille terminals, it's not surprising blind DEC users have switched to OpenBSD/VAX for their computing needs. It also helps that their Braille terminals were as well built (read: nearly indestructible) as their machines...
What I think is truly alarming is that a lot of blind users are switching more and more to Windows platforms, which -- due to the ugly GUI -- are the poorest solution for them. So porting EmacsSpeak to OpenBSD is a great idea. But what is urgently needed, today, is to raise the profile of OpenBSD (and open source solutions) among the blind community!
Thanks for raising this important -- and often overlooked -- community of hard-core CLI users.
Comments
By Amir S Mesry (208.52.133.98) on
> Thanks for raising this important -- and often overlooked -- community of hard-core CLI users.
I hope they become less overlooked, I think they could contribute to OpenBSD if they had better access.
By deanna (64.231.234.94) deanna@sdf.lonestar.org on
Some of what I wrote was conjecture, some was information I received from SDF users. What I hoped was to get a discussion going and find out what the reality is.
> But another thing to keep in mind is that a lot of blind users (at least in my neck of the woods) also prefer to use 'smart' Braille terminals (see here for a few examples) to access their machines. If they use that solution, a null-modem cable is the only thing they need to use an OpenBSD machine.
This troubles me, a lot. I can not get my head around why these devices are so expensive. I'd rather ignore that they exist than suggest that they are a solution.
Comments
By Noryungi (212.11.9.139) n o r y u n g i @ y a h o o . c o m on
This troubles me, a lot. I can not get my head around why these devices are so expensive. I'd rather ignore that they exist than suggest that they are a solution.
One thing to keep in mind is that the blind user 'market' is small and getting smaller all the time, at least in the richest country in the world. Well, that's the most frequent excuse given by the companies that actually manufacture these things. Also, they use expensive piezo-electric units to 'raise' the Braille points.
This being said, Braille Terminals are actually a pretty good solution. Once you get past the price, of course. What troubles me is that most Blind users seem resigned to their fate and are using stuff like Jaws and Windows, or speech synthesis, which are even more expensive and a lot more inconvenient... Imagine having a text read to you instead of reading it yourself. Just the sound of that robotic voice, after a few hours of work, is enough to drive you crazy.
Feel free to send me an email if you'd like to discuss this issue.
Comments
By Anonymous Coward (202.45.125.5) on
Out of interest, are braille terminals both screens and keyboards in one? Or are they used as a screen along with a seperate keyboard?
I realise screen readers would be annoying. I've heard them read everything, over and over, which would get old if a screen refresh was not all new material. But for people willing to use them, or if braille terminals are serial devices, even if only used for reading and not typing, I wonder if sparc64 would be a good platform for the visually impaired?
The reason I ask, is because in Open Firmware you can seperately assign devices for input and output. So could a Sun machine be configured in Open Firmware to use the keyboard for input and serial port A for output to a serial screen reader or braille terminal?
Comments
By Noryungi (212.11.9.139) n o r y u n g i @ y a h o o . c o m on
Out of interest, are braille terminals both screens and keyboards in one? Or are they used as a screen along with a seperate keyboard?
Yes, most Braille Terminals are actually divided into two parts: a Braille display, which uses piezo-electric contacts to raise or lower small plastic dots, forming Braille characters, and a special keyboard to allow users to type blind characters back into the system. Most also incorporate navigation keys, to scroll through an entire text screen, as they usually display only one line. See these two products if you need a better example.
I realise screen readers would be annoying. I've heard them read everything, over and over, which would get old if a screen refresh was not all new material. But for people willing to use them, or if braille terminals are serial devices, even if only used for reading and not typing, I wonder if sparc64 would be a good platform for the visually impaired?
The reason I ask, is because in Open Firmware you can seperately assign devices for input and output. So could a Sun machine be configured in Open Firmware to use the keyboard for input and serial port A for output to a serial screen reader or braille terminal?
Well, yes, OpenBSD/Sparc64 would be a good platform for this. But you also have to remember that any platform that can be connected to a serial device/terminal can be a good platform as well. The difficulty is not really in the day-to-day use of a given platform, it is mainly in the installation of OpenBSD itself. In that respect, platforms that allow the serial routing of the normal console to another (Braille) device is ideal.
Actually, one of the most important things to help blind users would be is a solid, stable and inexpensive Braille (or Speech/ScreenReader) Terminal to connect through a serial line to whatever platform they'd like to use. Again, the keyword is inexpensive, and that is something very hard to deliver, based on what I understand.
If such a terminal existed, OpenBSD would be a valid platform for blind users, thanks to its stability, security and wealth of command-line and text only applications. But the same could be said of Linux, NetBSD or FreeBSD.
By Anonymous Coward (156.34.216.110) on
A great portion of the web has become so inaccessible to blind users that it is insult to original web concept. Much of it is almost completely a visual media now. Blind users were better off in the days of Gopher.
By Anonymous Coward (63.237.125.20) on
SWI-Prolog is in Ports
"The Cynthia Speech Engine is a text-to-speech system written entirely in Prolog"
http://www.cynthiaspeech.com/
Could this be a path to screen reading in OpenBSD? I can see it coupled with ion.
Something good on the horizon for braille terminals:
The NIST Rotating-Wheel Based Refreshable Braille Display
The NIST Refreshable Tactile Graphic Display
http://www.itl.nist.gov/div895/isis/projects/brailleproject.html
According to NIST:
"It will make possible high performance Braille displays for $1000 or less, and enable high speed reading devices about the size of a portable CD player."
During install, "Change the default console to com0" and away you go...
Comments
By Noryungi (212.11.9.139) n o r y u n g i @ y a h o o . c o m on
> The NIST Rotating-Wheel Based Refreshable Braille Display
> The NIST Refreshable Tactile Graphic Display
> http://www.itl.nist.gov/div895/isis/projects/brailleproject.html
Wow! Have you seen the SIZE of this thing?
http://www.itl.nist.gov/div895/images/braille2.jpg
This may be useful for a workstation, but most blind people I know want notebook-sized hardware, not a huge monstruosity like this one.
Please understand this is not a criticism of this project, or of NIST, but it's certainly unreasonable to expect people to use this on a day-to-day basis. Also, please remember a lot of blind people have other handicaps, and may need help just to carry their things around.
By Anonymous Coward (216.220.225.229) on
http://live.gnome.org/Orca
By tspivey (64.231.232.11) tspivey@sdf.lonestar.org on
work (which it might) or brltty, I'd have an 80x25 screen. That just
seems so limiting. In Linux, or windows, I can have pretty much
whatever I need. Dispite that, my server is now running FreeBSD, and
hopefully soon I can get NetBSD on a few machines again. The server's
been up for 27 days, so it seems stable enough. I'm using it all the
time through an ssh connection, and have serial console access if
needed.
Deanna, I read your article, and everything there seems sound.
currently, I'm writing this in notepad because bboard's vi, jaws, and
other things hate each other. I just finished remastering (more like
tossing stuff in until it worked) GRML, a linux live-cd which has
speakup, for a friend. I would not give GRML to my worst enemy, at
least not in its default state. When booted, you can type grml swspeak
at the boot prompt. all goes well - flite says to type swspeak when
the system is booted. Type swspeak, everything seems good. type a few
commands however, and you start hearing: fdisk c, o, m... (starts to
spell)
This is some kind of a bug which only manifests when preempting the
BKL, since speakup is inside the kernel, and is calling out to
speech-dispatcher using its software synth module. We should have to
remaster an image to get a properly talking system; I remastered it
with espeak (http://espeak.sf.net) because it sounds a lot better than
flite, in my oppinion. This is what I like about open source - if
something breaks, I don't have to reinvent the wheel. I'm in college
now, and don't have hundreds of hours it would take to maintain a live
cd such as GRML. If anyone's interested in my remastered version, I'll
do a bit more testing, and send it to you somehow. I had to get rid of
tetex, but it has no reason to be on a rescue cd. I was considering
using GRML as my terminal, but running from cd is far too slow, and my
computer has a weird problem booting from the usb flash drive I have -
taking 2-3 minutes to even start loading the kernel.
Even speakup, being kernel code, has its problems - with the state of
the Linux kernel changing so rapidly, Speakup is hard pressed to keep
up - and when it does, a new bug might show up. I'm dreaming for a
system where most of the accessibility is written in userland, with
hooks in the kernel to take keypresses and give screen output. Yes a
talking bios would be nice, and i think it's needed - but so is an
accessibility API and tools. I don't know the first thing about coding
in C, beyond the basics - but I shouldn't have to. I should be able to
code my ideal screen reader in whatever language I want (perl/python,
ruby), and have it hook into the rest of the system. Yes this means it
wouldn't start before the userland was capable of loading, but speakup
could come in until the other system was loaded. There's yasr, but
Linux has no capability by default to take, for example,
capslock+anything and turn capslock into a modifier like JAWS will in
its laptop layout. I find this invaluable, and also another windows
program called autohotkey. This can turn your keyboard into just about
anything - but alas JAWS is too stupid (or maybe too smart?) and uses
its own keyboard driver that causes everything to go down hill. For
example, I can't vnc into it from anywhere, because jaws won't see the
commands. Window eyes, Hal, or even Voiceover on the mac work
perfectly with this arrangement.
On the subject of text editors - I swear by ed or edbrowse, and use
both those and vim. I use vim primarily for writing email, but might
start using it for other things because it supports other features
that ed doesn't (abbreviations, etc) and could be good for coding. Vim
would definately be my choice when using a braille display, because in
that environment, ed is an annoyance rather than a help - on a braille
line, you always know where the cursor is. With speech, in ed, if I
type =, it will speak the total number of lines. This even worked when
using my Braille 'N Speak in its terminal mode, which is virtually a
dumb terminal that can backspace. If my old dos screen reader (screen
power) supported cursoring properly, I could have used vim, but it
didn't have he delay.
In the current model, the OS isn't telling the screen reader much. for
example, if I press the left arrow under speakup, it waits (by
default) 120MS before speaking whatever is under the cursor - assuming
that the cursor has had time to move. I'm hoping for a world in which
the application tells the screen reader "The cursor has moved, I
pressed the h key, and it's on line x column x." the screen reader
could look up h, see that it's a character motion command, and read
the character. Currently, I'm restricted to arrow keys - I could
remap hjkl in my screen reader, but under ssh it has absolutely no
idea what program it's in.
I should be able to use the same programs that sighted people do with
the same access, if not better. I like using ed for most of my tasks,
but vim is good for things such as changing one character in a line of
similar characters - I don't want to make up regular expressions for
every weird change, but at the same time I don't want to have to
remember just how many characters to change and where they are when I
want to replace "teh" with "the". Case in point - I'm currently
editing with notepad - if I hit control-backspace, it just spoke
"comma" - which, from experience, I know wasn't deleted. Instead, I
hit left arrow and it says nothing. I have to hit another key to know
that it's some extended ascii character that it put into my file,
which is useless.
I think that command lines are the way to go. Taking it to an extreme,
we could have the shell, and a mail client that sits on top of the
shell, like nmh, but with more features, and modernized. I like mutt,
but I feel more comfortable in a shell. If I launch mutt, I can't use
j/k to move down/up, or it will read weird information - I have to use
arrow keys, or use j/k, but after I press it, read the current line.
That can work, but I just want access to my info. To that end, I have
mutt ignoring all headers, a simple index-format, and my prefered
reading method is to sort by threads, and delete uninteresting ones. I
sometimes hit enter, and just keep deleting and reading - I can plow
through messages quickly. That's not the point, though - the point is
that I should be able to do that, but with even more access than I
have now. Yes there's emacspeak - but it bugs me. My dectalk lags for
about 2 seconds each command under emacspeak, which is unacceptable
for a speech solution. And no, the serial cable isn't in backwards, as
sometimes suggested as a troubleshooting method on the list. :) Part
of the problem is the dectalk - when switching voices, it puts a delay
in - and after each speech processing command. I can rant about that
later, since this post is getting extremely long now. If anyone has
any questions, mail me at SDF, since I seem to be here alot recently.
By Marc Espie (213.41.185.88) espie@openbsd.org on
Screen has got an shm flavor that can combine with brltty to
enable the use of a braille terminal.
Someone enterprising could probably hook up brltty with wscons directly,
btw.
And there is also some speech synthesis system in the tree.
It's big, it's called festival, and it works quite well.
Back when I was porting kde's accessibility, I had a look at
the speech synthesis facilities it can use (after all, there are
more than blind people that can use speech synthesis facilities...
some people have just enough sight to make sense of a gfx interface,
but cannot read texts on the screen).
Surprise: most of them are not really free, and require licences,
or are linux-only.
This explains (partly) the lack of more such applications on OpenBSD.
That, and, as correctly assessed, a lot of speech synthesis facilities
are research-material dependent on some fairly specific languages,
and it's a bit harder to port stuff over when you have to build the
whole system first...
By Mario Lang (129.27.9.73) mlang@delysid.org on http://delysid.org/
It might be true that speech-only screen readers
are not that well ported/available for OpenBSD
yet, but I can at least report from the Braille output
front, which is what I use: BRLTTY, the IMO most used
Free Software screen reader for braille terminal
users is ported to OpenBSD since about 2 years
(Dave Mielke, the maintainer of BRLTTY, and I, worked on that)
If it wasn't dropped recently from the ports-tree, it shoud
readily be available from there.
The only problem here is that virtual consoles can not
be reviewed with BRLTTY on OpenBSD since there seems
to be no kernel interface for user-space apps to review
virtual console content. So a patched version
of screen (SHM) has to be used so that BRLTTY can
retrieve the screen content from screen directly.
Maybe OpenBSD could look at implementing something
alike to Linux's /dev/vcs devices.
brltty: http://mielke.cc/
P.S.: The "Proove you are a humkan" bit on this site
almost prevented me from writing this reply.
I had to post the ascii art on IRC and get someone to read it for me, since that is not easy (with braille)
and impossible with speech-only output.
Comments
By deanna (64.231.232.11) on
> It might be true that speech-only screen readers
> are not that well ported/available for OpenBSD
> yet, but I can at least report from the Braille output
> front, which is what I use: BRLTTY, the IMO most used
> Free Software screen reader for braille terminal
> users is ported to OpenBSD since about 2 years
> (Dave Mielke, the maintainer of BRLTTY, and I, worked on that)
> If it wasn't dropped recently from the ports-tree, it shoud
> readily be available from there.
Thanks, that was a pretty big oversight on my part and I've corrected it in the article, so no one gets the wrong idea.
As I said in another comment, I am more concerned with TTS right now, because it's much less expensive, and may open doors to people who never considered using a computer at all. Of course braille support is important, and thank you for the work you've done. But what I'd also like to work on is making it so a person could pick up an old machine at the Goodwill, load OpenBSD on it have it be immediately accessible.
Comments
By Anonymous Coward (220.233.103.7) on
> As I said in another comment, I am more concerned with TTS right now, because it's much less expensive, and may open doors to people who never considered using a computer at all. Of course braille support is important, and thank you for the work you've done. But what I'd also like to work on is making it so a person could pick up an old machine at the Goodwill, load OpenBSD on it have it be immediately accessible.
Nothing wrong with using serial, I did all my Unix for years from my c64 hanging off a serial port.
By Anonymous Coward (205.166.76.15) on