Slashdot Mirror
Designing an OS for Blind/Deaf Users?
Sushant Bhatia asks: "I work for a team developing technology for individuals who are blind and I have had the opportunity to use some screen reading software and while there have been leaps of progress it is still quite tedious to use, and not at all user friendly. One of my managers recently posed an interesting question for me: 'How would you design an OS from scratch that would target individuals who are blind and/or deaf?' What about inputs such as keyboards or refreshable Braille devices?"
maybe i'm being obtuse, but wouldn't the sole useful input method for the blind be verbal? as for the deaf: why would you not use a GUI? this seems too simple so what am i missing?
ed
Really if you are going to take only text as input and output is going to be serial text, speech (blind but not deaf), braille CLI is the way to go.
This does not prevent you from multi tasking BTW, it simply means that you need to work within a well defined context.
Nothing new to invent.
EA David Gardner -"... but the consumers have proven that actually what they want is fun."
What is the point of that? Braille is meant to be felt, and would have no purpose on a screen
Dude, read it again. I'm suggesting that they have a screen that they can *feel*. Regular characters would be very difficult to discern on such a device, so changing the fonts to braille is the best solution.
Javascript + Nintendo DSi = DSiCade
I think this is one of those cases where it isn't mere pedantry to point out that the OS and the shell/interface are two very different things and that what you want is an interface designed from scratch for the blind.
You can use any already existing decent OS as the base.
You do not have to reinvent the wheel to invent the wheelchair.
If it were me I think I would start out by trying to scratch build a decent IRC client. What you learn by doing that will teach you things you will need to know about such interfaces before you start out at a lower level.
KFG
Mac OS 9 was the most blind enabled ever, even for 'refreshable-braille"
... same thing... but the issue becomes a matter of two handed browsing on a screen. On hand moved on a tablet and the other hand received braille on fingertips
The reason... for the first 10 years maybe 15 years EVERY developer followed EVERY rule and used the official GUI and official controls (with text labels in them) and the compter gui was also mode-less, as well as very intuitive.
Sadly... apple hired cretinous morons who destroyed the gui in apples own idiotic tangential offerings ruining everything.
At one point in their own written standards manual 'HUMAN INTERFACE GUIDELINE" apple proposed that COMMAND-C which means "copy" (except under a few versions of dvorak keyboard mappings) was to not mean copy, but was to mean "CANCEL" if a cancel button was visible in a dialog!!!! HAHAHAHAHAHHAHAH
The Next was idiotic in version 0.9 of NeXTStep OS and Command-2 was duplicate but they eventually changed it to Command-D for all apps.
But OS9 was flawless, and every app worked well with blind software, and people rarely double bufferred pixels, and even if they did, it was easy to track the blits because the OS bitcopy commands were always used by all programmers so text strings could still be located without ever ever using "screen scrapers" to perform OCR crud.
Blind worked great on macs.
As for blind-AND-deaf
eventually i got a job at a company that sold such software (AT A FINANCIAL LOSS BUT FOR CHARITY) called Berkely systems. They even employed fulltime blind employees to test the windows-only version which was a poor substitute for perfect competing mac OS9 versions. Why? becuase no wintel idiots followed any standards ever for getting text onto a screen or following GUI guidlines for controls.
The Mac OS9 is still useful. might as well stick with it. Apple distributed LowVision screen zoomers (an optional control panel on the installer CD) for years standard free with all copies of mac OS for people with extrememly poor vision.
Braille consists of raised bumps. "Inverting" them, i.e. turning them into dents, renders them essentially unreadable.
Sorry, I was unclear. I was referring to icons and buttons being inverted. Text should never be inverted, but should actually be raised when selected. Thanks for catching that.
Javascript + Nintendo DSi = DSiCade
Cut costs there, sure. But other possibilities exist. Would you really need as fast a processor on a box like this? Your output needs/speeds may not be as high as the needs of a traditional user. I am not a deaf or blind user (IANABODU henceforth), but I'm assum... stating that these should be different machines. Think of the possible needs/lack thereof.
Visually impaired: video drivers possibly not needed; traditional 3D gaming not an option; output devices less resource intensive (no monitor may be needed); no traditional high-resource GUI needs (skinning, fading, etc). There may however be some needs that are not listed here. For example, if you have a visually impaired audiophile who enjoys running resource-intensive software apps, a beast of a computer might still be what the geek ordered. Again, IANABODU.
Audio-impaired users would have needs largely similar to those of traditional users, and perhaps then some. Either way, speakers may not be needed, or sound cards, etc. Since sound is included on so many mobos lately, it's probably more expensive to remove it than it is to keep it. Again, IANABODU.
Another statement that should be made is that the typical user doesn't even use a fraction of what their computer can do. How many users do you know who purchase 3.x Ghz wintel boxes, just because their 2.4 Ghz is a year and a half old, just to camp in front of it and use IE/Outlook/Solitaire?
Now accepting PayPal donations!
I knew a pair of blind gentlemen who worked MSN Tech Support, and we set up a computer for the two of them to learn MSN Explorer with JAWS piped to speakers so they could both listen together.
The experience left me both in awe of their ability to hear all sorts of detail and in disgust at the lack of accessibility. The the custom interface was made out of poorly named images. One particularly useless one (Image 14, IIRC) was the minimize, maximize, and close buttons, all together. This brought me to my thoughts on a vector-based UI. Imagine the convenience of smooth scalability across different resolution displays...
Anyway, concerns that I can think of are as follows:
1. API
A series of abstracted interface methods should be made available. The categories are pretty simple... User Interface (menus, buttons, inputs), Text (static & editable text), Media (audio, video, pictures)... this is all off the top of my head, so feel free to improve on it. Each category simply defines a type of data, and then you can build ways to retrieve or interact with it.
2. Registration
I don't care if everyone puts their close button in the same place with the same icon. Visual users can typically locate these things. What they should do is then register that component with the UI Manager. Components could fall into multiple categories, i.e. a graphic on a web page with URLs mapped on it is both a picture and a series of links. Add a "group" indicator or hierarchy to properly collect controls and data together, and I think you have the basic needs covered.
Using these two parts, we should be able to build simple command interfaces. The ability to define the set of controls, displays, and texts for a given interface means you can see them all at once, or hear or feel them in sequence. Your interface can choose to discard or delay extra media (no sudden advert noises on audio interfaces or no need to waste processing time on decoding the video portion of a media file) through a variety of user-adjustable settings.
For visually-impaired individuals, I think the vector-based interface could make huge strides. Right now, you can buy a 21-inch monitor and set it to 800x600, or use a projector, but new laptops are still 1024x768 or higher. I listened in on a Dell Customer Service call from an older gentleman who loved the laptop he purchased, but couldn't read the high-res screen. If a vector-based interface was available that allowed his to change the point size - similar to Mozilla's Ctrl-Scroll size changes - he would have been fine.
I think the key, and the hard part, is getting buy-in on this kind of pervasive detailing of interfaces. HTML/XHTML is a great start for this, because this kind of extension is very easy based on the nesting and pre-defined components on a page.
Interfaces for the disabled or impaired could come in handy for everyone. These same advances are where the "technologies of the future" come from. Until we push the mouse away, we're stuck to the desktop metaphor.
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
By way of background, he uses his computer (a Windows box on a university network) for e-mail and writing scholarly articles. His screen reading program is JAWS. He would like to use the internet more, but he's frustrated by a combination of factors, some JAWS-related and some related to inaccessible design. The boss is highly intelligent and has been blind from birth. He's very used to other adaptive technologies like Braille or Open Book (a program that uses a scanner to translate print to speech), but he's a complete computing novice.
It's worth noting that the computing problems he has are completely different from those that I would face if I were blinded tomorrow. A lot of his trouble is just related to a poor grasp of fundamentals. It's very difficult to explain the difference between opening a folder on the desktop and browsing the contents of a folder through an application's Open dialog box. Compounding the problem is that the boss is ten years late to the party, and most of his sighted assistants take things like right clicking on objects for granted.
On the other hand, he has some advantages that a recently blinded person would not. The boss is used to taking in huge volumes of information through his ears, and can absorb synthesized speech at a dizzying rate. He also reads and types Braille grade 2, and gets a lot of use from his Braille Lite, which is like a PDA for Braille users, with a special Braille keyboard and a refreshable display of dots. It's great for him, but the chord- and abbreviation-based systems of Grade 2 Braille, take a long time to learn, and wouldn't be useful to your grandmother, who's losing her vision to diabetes.
So here are some of the problems I've encountered in my time with the boss:
John Hancock wuz here.
That is exactly what I tried to do when creating libbraille... an open source (LGPL) library which supports more than 30 types of Braille displays (PulseData, F* Scientific, Blazie, EuroBraille, you name it...) with a simple common API.
I can't really say that Braille display manufacturers are very cooperative (they are not _at all_). Which is stupid since this project has facilitated the creation of many applications using Braille displays, which in the end helps to sell more Braille displays.
Since those Braille displays are very expensive (usually >5000$), I also created a virtual graphical Braille display with Gtk+ which can be used by developers to test how there application would be rendered in Braille. So feel free to test it...
One of the most useful things about a GUI is the visual cues that it gives to jog the memory. CLI is often more powerful, but it is lacking in visual cues and so takes longer to master because you have to remember everything.
So, what about creating some sort of sonic scheme for locating the user in 2d or greater sonic "space" that's equivalent to a sighted user's peripheral vision giving information about the GUI environment. I'm thinking perhaps musical chords could represent different parts of the "sonic desktop" and that chorded input could provide navigation for sightless users. Perhaps the keyboard could even be completely replaced by something like a stenographer's keyboard, where chorded input is the norm.
nuke the moon