Apple Education and Screen Readers

[@HomeNow]

I agree that Apple should pursue writing this software. After having worked on some pilot projects with accessibility for educational publishing, and working with CAST on a similar project, I think that this is an area that is lacking on the Mac side. The solutions that are out there for the PC are also crude in my opinion. Apple could improve on the implementations of this software and bring about a big plus for the Mac platform. This has been an area in software development that Apple has accelled at in recent years.

However I disagree that this should be open sourced. This is an initiative that requires consistency in the way it works just as a GUI requires it. To achieve this Apple should keep as much control over it as possible. To allow it to be open sourced could bring about confusion in its implementation which could adversely effect the reputation of the software.

As for cost, it would be a boon for Apple to offer it for free to education. However, based on the cost of the screen readers that are on the market today I think that Apple could easily get away with charging $25-$50 for it and still attract people to the platform. This is after all a strain on Apples resources, and to do it right they would have to support both audio screen reading as well as braille screen readers put out by third parties, and this would cost Apple quite a bit of money. While I like to get "free" stuff as much as the next guy, I don't expect Apple to give everything away. The only upside to making it part of the OS is that it would make it easier, and less costly for web developers to support and develop for 508 compliance on the Mac. But the truth of the matter is that it takes considerable cost in man hours to ensure this compliance, and the majority of the developers that have to do it will cut costs by troubleshooting it for as few browsers as they can get away with, which means testing it on various versions of IE.

 

[ffakr]

I don't know as much about this (legally) as a few of you, but I have managed Mac labs in Edu. At my last position, the Disabilities dept. was perfectly fine with the use of OS 9's built in accessability software. We did have JAWs installed on the PCs though.

The general rule which we lived by was that we that we had to make "reasonable" accomidations for handicapped students (though we couldn't always call them handicapped).🙄
We didn't have to take any steps which were beyond our ability to provide, financially or technically, though we did our best to be as helpful as possible.
As mentioned elsewhere, we had to try to provide the same services to every student, handicapped or otherwise.. if at all possible.

Just to prove how open the relevent 'disabilities' acts are, my current employer, a University with a rather famous history and present, has areas that are pretty much impossible to access from a wheelchair. There are buildings I support where I've yet to find a ramp into or out of. The only caveat is that it isn't a public university, but it does get a LOT of federal grants.

 

[finelinebob]

I don't think the point of Apple open-sourcing something like this would be to expect too much development by others out there but, rather, to provide a solution for the community that may not be out there. Maybe someone in the studio audience can fill us in on the state of screen readers in the Unix/Linux world.

Either way, it's not the GUI or the features of the software that would make it a Macintosh program that would benefit Apple or others from it going open-source -- it's the underlying engine.

On second thought, Apple may have a helluva lot to gain from independent developers on this one. The English language is a beast to comprehend and there are some big disparities between how it gets written versus how we speak it. Dealing with those disparities can lead to some pretty stupid, arbitrary solutions. Case-in-point: I know of a blind lawyer who would scan correspondence sent to him then use an OCR-to-Speech program to read him his mail. Was driven to distraction at why judges were being addressed in overly-familiar terms. Well, the developers of the software made an arbitrary decision to have the software interpret these four characters -- hon. -- half the time as the word "hon" (short for "honey") and a period and half the time as an abbreviation for "honorable" (as in "the Hon. blah-blah-blah").

Sure, putting some bug feedback feature like Safari has into such an as-yet-mythical offering might be a solution, but getting this thing (much closer to) right from the start would be critical for a population already snubbed by much of the computer world.

As for giving it away to education? Sounds like "selling music at 99 cents a song in order to sell iPods" to me. The potential for recapturing market-share in education is too great not to entice educators with this. I know others have posted just how expensive individual licenses for (Windows) screen reader programs are -- often as much or more than the cost of the computer ... seen them for myself as well. Can't say what site licenses might cost for such software, but I'm sure they're a helluva lot more than "Free".

 

[finelinebob]

oops. Pardon my ethnocentricity....

Another big reason for open-sourcing something like this? How many languages is Mac OS X available in?

Translating menu items is one thing. Entire languages? Quite another. Localization of the software for non-English speaking countries is one place Apple and everyone else involved could benefit greatly from if they ARE doing this and if they DID open it up.

Again, it's not an issue of implementation but the underlying engine. What would that involve? Language libraries/dictionaries, rules of syntax, I dunno. But nailing the engine would allow Apple (and others) to figure out not just how to implement it right but where (in the computer, in other programs). Imagine having the screen reader in the Services menu. Yes, I know ... "Speech" is already there -- but screen readers need to be more that Text-to-Speech programs. Good ones read the "metadata" in web pages and translate that as well. Hmm ... then that might mean Apple (and other vendors, to be fair) would have to start making it's own data file storage system more metadata-rich...

 

[simX]

Maybe I'm missing something here, but aren't screen readers precisely for people who are only partly blind, not totally blind? Because it seems to me that even with screen reader software, using a computer when you can't see what you're doing is way too complicated. You wouldn't be able to see where the mouse is going, and you would miss out on much of the graphical aspect of an operating system. I am kind of doubtful as to whether screen reader software can usefully translate every part of an operating system into sound for a blind person who is operating the computer.

I would think that the existing zoom option built-in would be sufficient enough. You can have all interface items read themselves aloud when you have the mouse over them (System Preferences -> Speech -> Spoken User Interface -> Other spoken items -> Text under the mouse). And you can select any text in Safari or any other application that uses text and have Mac OS X speak it aloud.

Is there something I'm missing?

 

[andyduncan]

Originally posted by simX
Because it seems to me that even with screen reader software, using a computer when you can't see what you're doing is way too complicated.

...

Is there something I'm missing?

No screen reader could realistically give you as much information about your computing environment as a gui could. What they do is make it possible to complete tasks that would be impossible otherwise, even if it takes a little longer.

The ideal screen reader would be someone sitting next to you, who knew what you wanted to do, and could describe what was appearing on your screen (and like I said before, this does happen quite often). Even the best software can't get close to that level of speed or accuracy, but with the help of the application/web developers and the operating systems developers, it can get pretty good. And it can certainly be enough to accomplish a specific task.

If you think about the most important information on your screen, it's usually text anyway. All those extra graphics add meaning and make it easier to understand, but theres a lot of information that can still be conveyed without them.

This is really the whole point of accessibility, and the idea behind stuff like section 508 or the WAI: Go ahead and add value to your information with graphics and color and animation, but make sure that the people who don't have access to those "extras" still get the underlying data.

From an App developer's standpoint, OS X has a lot of nice capabilities that make it easier to be accessible (there's a ton of stuff on developer.apple.com if you're interested). The main glaring absense is a lack of software that hooks into that accessibility framework. It's great that Apple is taking charge and doing this in-house.

In addition, screen readers should be considered part of the operating system, not some type of third-party app. Smaller shareware (or opensource) developers aren't going to shell out $1000 for screen reading software (or even bother downloading a demo) just so they can test the next version of their app against it. They are much more likely to fire-up the screen reader if it's already included. They are also much more likely to ensure that their app works with The screen reader for the operating system instead of One Of the screen readers for that operating system.

This is A Good Thing™

 

[finelinebob]

Originally posted by simX
Maybe I'm missing something here, but aren't screen readers precisely for people who are only partly blind, not totally blind?...

This article at A List Apart, while on accessibility issues about Flash, has a good description about what screen readers are and what they do, as well as a few links to some of the big ones out there: http://www.alistapart.com/articles/flashmxclarifying/#srdefinition .

No sarcasm intended, but yes, Graphical User Interfaces aren't all that usable for people who are totally blind. I'm not blind myself, but I can understand mouses are being rather pointless (figuratively and literally). All the same, as a touch-typer I don't have to look at my keyboard (ok, most of the time) in order to express myself on my computer and I know how to navigate fairly well through most web pages without ever touching the mouse as well -- links and form elements, as well as the address bar, are generally well-supported by at least tabbing through them and using the return key to activate them, even if browser support for custom-coded access keys is not. The MacOS used to have fabulous support for keyboard navigation, even inside open and save dialog boxes, but from from what I've read about Panther this support has taken a few steps backwards ... don't have it myself, so I can't say.

The short of it is this: people who cannot see need something other than GUI software interfaces and related input devices to make use of a computer. Screen readers -- not simple text-to-speech programs -- try to provide this while making use of what input devices are available (including things like Braille displays).

 

[@HomeNow]

As I understand it, screen readers read the screen, and or alternate tags that are embeded into screen items. They do not translate this information, thus the hon. vs. hon (honey) would not be a problem. For 508 compliance there are both long and short descriptions that are "hidden" in the code for for graphics., a profesionaly developed and compliant site or program would most likely havespent a lot of money on writers, editors, proof readers, editors and copy editors to get these tags just right, and would not want a program "messing" them up by paraphrasing them. The big thing that is lacking on the Mac, as I understand it, is keyboard Navigation and its integration with Apples text to speech technology.

 

[finelinebob]

What makes things complicated, tho, is that not every task you can do on a computer can be done in a web browser. Other applications that could be accessed through screen reader technology won't have the metadata that HTML tags can bury beneath the displayed text for intelligent clients to interpret. You're not going to see support for anything like <acronym title="Honorable">Hon.</acronym> in Word or an OCR program or mail reader/writer, and most people don't want to learn HTML so that they can put such information into their writing even if the support was there.

Even with web sites, yes, well-designed, Section 508-compliant sites will have this information. But when will the Feds ever require that all commercial and private web sites be 508-compliant? They can't. So, having a screen reader rely on X/HTML + related technologies and the graces of developers/copy writers/project managers/executives with decision-making power above them to implement these measures is selling the potential of the software short and limiting the range of use where it is needed.

And screen readers DO need to "interpret" to be effective. If you read: This? or This! or even This?! you have some idea that I meant something other than This. Computers reading back text in a monotone is so cliche its a joke these days, not just because its technologically archaic but because people know well enough (intuitively, if not overtly) that voice inflection carries a lot of meaning, even more than the actual words spoken at times. In written language, we have things like punctuation to help but often have to use things like context to convey what our voices can carry. Obviously, this creates a lot of trouble for Speech-to-Text, but translating our written language devices (like punctuation) into spoken language devices (like inflection) is just as big a problem going from Text-to-Speech. Any screen reader or Text-to-Speech software that reads This. This? This! and This?! identically is not doing a good job.

[Just checked myself -- Services > Speech > Start Speaking Text. Some very minor inflections ... somewhat remarkable for one-word "sentences" ... but they are there.]

One of the things that, for me, makes the prospect of Apple screen reader software so interesting is that these days (forget Apple of the 90's and how many projects they abandoned), when Apple goes for something like this they go all out to do it right and THEN some. An article I read recently pointed out how with Safari Apple has done in short order something Netscape took over 4 years to accomplish, and only by opening up Mozilla to open source developers. Forget about IE, even WinIE -- as a web developer, I can tell you that WinIE6 has taken steps backwards in terms of its standards compliance. On top of how well it handles web pages, Safari has also tried to re-invent two critical aspects of browsing -- handling bookmarks (which many people think they've done an incredible job with) and handling navigation with SnapBack (which I really haven't read much about but, in trying to introduce a new navigational metaphor, is in many ways more revolutionary ... if it works).

So, what does that drive for excellence mean for a screen reader? It seems to me that Apple wouldn't just look at what the cream of the crop of screen readers today do right, but they'd also look at what they need to do or what they could be doing. If Apple is focused on raising the bar for what the user experience is like, then there is a lot of room for improvement in this area.

 

[Doctor Q]

Screen readers are indeed used by the totally blind, including some of the customers of the company I work for.

It will never be possible to make it as efficient for the blind to work with a typical program as for a sighted person, simply because they have less "input channels". You might make up for some of it by using tactile feedback or more varied auditory feedback, but the first goal is for total capability, not total efficiency. In other words, the starting requirement is that every piece of information be obtainable and every feature of the program be usable (excluding visual-only features of no interest, such as the color of the desktop, the pixel layout of an icon, or iTunes visualations).

To make a program equally efficient for the blind and sighted, you would have to engineer it so that the visual parts were only one alternative among many, with no efficiency benefits over the other choices. This isn't practical, because it would be too limiting for sighted users. For example, the most efficient way to invoke a menu choice is to hit a keystroke or two. Yet, for most menu selections, sighted people still prefer to drop-down a menu and pick a choice they see. A screen reader could read all the choices in the menu, which is effective but not as speedy. Having both choices benefits everyone. And we wouldn't expect a software vendor to level the playing field by making keystrokes the only way to select a menu choice.