I pretty much know all of this today. All of those years ago, though, when we set out to do Java at HJ, we were advised and helped by the Sun team to do the work through the bridge which has sort of left the FS buys in a strange state as it's even hard to find someone at Sun to really advocate for the bridge anymore.
On Feb 18, 2009, at 12:45 PM, Macarty, Jay {PBSG} wrote:
Chris,The unfortunate aspect of this is that FS, at the time, may not have realized that there were, in fact, alternative mechanisms for getting to the java accessibility API rather than the access bridge. Granted, they would have likely had to develop whatever bridging technology they wanted to use, but given some of the negative impressions people have gotten regarding the JAB, maybe, it would have been worth it. <smile>When it gets right down to it, the Window-Eyes interface is using a bridging technology as well in that it uses a java-to-COM API. It's really a matter of what and how the information is sent across a given bridge that can create a perceived, if not real, sense of java accessibility. The Window-Eyes java interface and the JAB are monitoring the exact same event queues and pulling data through the same accessibility framework. Unfortunately, the event queues inside a java JVM can be complex and even chaotic at times. So, a major goal of any access/bridging technology is going to be how to effectively manage event data coming in from multiple threads and structure it into something a screen reader can reasonably hope to count on to deal with.-----Original Message-----From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx ] On Behalf Of Chris HofstaderSent: Wednesday, February 18, 2009 9:39 AM To: programmingblind@xxxxxxxxxxxxx Subject: Re: GW Micro Announces Support for Java ApplicationsI don't know anything about how GW handled their Java implimentation but having lived through the HJ/FS battles with JAVA, I can state with some authority that unless the screen reader companies would join together and build a common Java presentation layer, they will probably not even be similar let alone "write once, play anywhere..."FS code is bound to the Accessibility Bridge, we made this decision because that's what Sun told us to do. The bridge has migrated terribly and is still something like supporting a random number generator as regards the order in which events are fired - this makes it a real bitch to make a screen reader deal with complex situations as we couldn't make any assumptions.Wandering away from the bridge approach might make the GW solution better, maybe even much better. Compatibality with JAWS, though, is lost in the sauce. Thus, one who makes a Java application probably needs to test both to assemble a decen't VPAT.cdh On Feb 18, 2009, at 12:32 AM, Macarty, Jay {PBSG} wrote:Ken, Addressing this topic of binding to a specific screen reader, what I really want is the best of both worlds. I want a technology agnostic access, just like java uses for database access or messaging, where the java code itself uses a generic interface with the exact implementation of getting the speech or Braille out the door, so to speak, is handled by a service provider under that interface.As Jared points out, I'd like the flexibility of having support for 30different speech synthesizers and 20 different Braille displays by creating a service provider that channels its activities through a screen reader. On the other hand, if I want to write a simple wsc wrapper around a SAPI interface and be completely screen reader independent, I think my code should be able to offer that just as well. In truth, a java accessibility technology should strive to keep in line with the java mantra "write once; run anywhere". Ideally, Access to what is happening in a java application shouldn't be limited to only those screen readers willing to implement some particular interface technology and the screen reader in use shouldn't dictate how accessible java is. How effectively we get there is still to be seen. <smile> -----Original Message----- From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx ] On Behalf Of Ken Perry Sent: Monday, February 16, 2009 6:04 PM To: programmingblind@xxxxxxxxxxxxx Subject: RE: GW Micro Announces Support for Java ApplicationsShrug I just don't know why it's being tied to one screen reader but Iwill stop complaining. I just am not a fan of any of the screen readers and this just forces us to use one for one thing another for another thing and well I am just sick of it. Grr never mind. I will go away and work on my other screen reader for the quantum universe. Ken -----Original Message----- From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Macarty, Jay {PBSG} Sent: Monday, February 16, 2009 2:33 AM To: programmingblind@xxxxxxxxxxxxx Subject: RE: GW Micro Announces Support for Java Applications There is a fundamental difference in the approach that the access bridge took to exposing the inner workings of java to a screen reader and that taken by WE4Java. Basically, the JAB Takes java objects and events and translates them to objects with handles which the screenreader can more easily obtain and understand. It doesn't reproduce the objects themselves (in other words, it doesn't take a swing button andtry to reproduce it as a windows button); however, it exposes objects which the screen reader can get and evaluate. WE4Java, on the other hand, exposes no object handles to the outside world. All object and event monitoring is managed inside the java virtual machine and then WE4java utilizes the speech, Braille, dialog, and sound capabilities of the screen reader by calling those functions. WE4Java can pass along to the screen reader as much detailed information about the running java application as the screen reader wants to see. With the JAB, the screen reader is limited by what it can gather from the exposed objects. I am continuously working to deliver more and more data to the screen reader and let it decide what it wants to do with the info based on the user's verbosity settings and/or other preferences. Java sometimes gets a bad rap regarding accessibility but it isn't actually java itself. It is just that the screen reader can only know what it can know. WE4Java simply attempts to make that information available in a different manner. -----Original Message----- From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Jared Wright Sent: Sunday, February 15, 2009 12:16 PM To: programmingblind@xxxxxxxxxxxxx Subject: Re: GW Micro Announces Support for Java Applications On 2/15/2009 10:27 AM, Chris Hofstader wrote: "JAWS has had Java supported for five or six years now." Really? I thought I paid attention, and I was under the impressionthat UI's made with the Swing library were cumbersome at absolute best and usually lessfor just about all screen reader users. Using WE4Java,I can say I'm having my most tranquil and pleasant experiences with commercial level Java software. As far as why it's not working with other screen readers, I haven't the knowledge to say. Perhaps Jay would enlighten us as to that potential. I'd be curious myself. Jared __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind__________ View the list's information and change your settings at //www.freelists.org/list/programmingblind __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind
__________View the list's information and change your settings at //www.freelists.org/list/programmingblind
