Accessibility and Citrix?

Brian asks: "It appears that Citrix Metaframe 1.8 does not support third party voice accessibility programs, like JAWS. Has anyone successfully implemented federal accessibility guidlines for software that is running through Citrix or other tools like pcAnywhere? I have been on several projects now where Citrix is being used to 'web enable' a client/server application, only now to realize we can't meet federal accessibility requirements this way. Any thoughts?"

Re:Use Linux

[Octal]

Obviously.

Re:I know it's possible....

[Rendus]

The KB article I was reading had to do with Microsoft's voice synthesizer for the deaf speaking your password out loud,

Well, that explains some things about MS software... Speech for the deaf, enhanced fonts for the blind? :)

Don't nitpick

[scriptkiddie]

you know what I mean...

:)

I know it's possible....

[scriptkiddie]

Today I was looking through some Microsoft Knowledge Base articles about something unrelated, and I found a bunch of stuff about how Microsoft's Terminal Services accessibility API has some bugs when working with Citrix. Clearly, if it has bugs, it must exist (though the inverse may only be true with Microsoft products).

The KB article I was reading had to do with Microsoft's voice synthesizer for the deaf speaking your password out loud, even though it isn't echoed to the screen. Apparently RDP sends meta-information about the text on the screen just so accessibility apps will work but isn't smart enough to realize some information shouldn't be sent.

So it sounds like you could restrict yourself to using Microsoft's accessibility products, which are mostly developed as proofs-of-concept in research labs and aren't very polished. Or you could just give people who need accessibility apps access over SMB (hope you're not doing something fancy with DCOM or ODBC....).

By the way, this is precisely why terminal apps should send more than just a bitmap of the screen. You can't have the server preemptively deciding what data the client might possibly need and sending it off - what if the client needs to print a file locally, or save a screenscrape to disk, or change the app's resolution to fit the local screen? The ideal thin client architecture would transfer the GUI to the client at runtime, then use an RPC system to send input and events back and forth. HTML comes close and DPS comes closer, but neither are really solid. I'm contemplating doing a demonstration of these semithin clients in Python, but it's a lot of work.

Good luck!

VNC

[e-jewel]

Perhaps I am missing something as to the potential use you had in mind, or whatnot, but perhaps you could look at the GPL'd VNC software now "owned" by AT&T research labs UK. If it doesn't meet the federal standards you mention, you could bare your arms and crank out the code to do it yourself. Then, if you're really nice, you could submit your changes back to the VNC project. Ah, the unadulterated glory of living a moral open-source life!

On the client

[LagerFrenzy]

You need to load the voice software on the Metaframe client PC. You also need to publish individual applications rather than the desktop in order to get context. It's not thin client, but it should work.