DACX meeting minutes
Closing-the-Gap
Thursday, Oct. 21,1993
Meeting called to order at 8:00 pm. Additional copies of the agenda were distributed to the everyone in attendance. Individuals at the meeting introduced themselves. List attached at the end of the meeting minutes.
(Note: I tried to identify each speaker during my transcription of the meeting minutes. Unfortunately, sometimes I was unable to determine from the tape who was speaking, or what they were saying, so I labeled these areas with "??". I apologize for any misrepresented parts of the following minutes. Mark Novak)
Mark: Call for adding items to the agenda. No response.
Mark: Call for old business discussion. No response.
Mark: Call for new business. First of all we will have a review from some of the subcommittees that have been working on the DACX project for the past year. I would like to call on Earl Johnson to give us a report on what Sun Microsystems and some other companies have been doing in the area of mobility access to X to bring everybody up to date.
Earl: I have a few overheads that kind of look-see what AccessX is. AccessX prototyped in X11R5 has been completed. We completed the server stuff which was primarily developed by DEC. The user interface stuff, which is the first window that you see up here, is the main window where you get indication of the status of StickyKeys, ToggleKeys, etc., and the enable of AccessX giving you sound, etc. You also get primary features that you might want to change frequently. Down at the bottom you see the settings window which calls up the features adjustment window. Here you come in to make modifications to the speed of MouseKeys, acceleration of MouseKeys, the repeat rate, the delay until repeat, etc. Basically, any functions that you can change in the AccessX, which I am assuming everybody is kind of familiar with. This is where the features are adjusted. This isn't a user interface that is up all the time, again, it is the main window that is typically up. Three of the windows that aren't shown are the help window. There is online help for StickyKeys, RepeatKeys, SlowKeys, etc. those types of features. There are also two status windows for both MouseKeys, which gives you an indication which mouse button is down, and StickyKeys, which is an indication of which modifier key is down (control, alt and shift, etc.). These have been completed. Since their completion, Silicon Graphics has come up with a proposal for X11R6 called the XKB and because there was so many similarities between the server aspect of XKB and the server aspect of AccessX, all the AccessX features were rolled into XKB and now they are available through the alpha version of X11R6. The user interface that will be used is the one that you see up here. It was developed kind of by all three members. The primary members that developed this were the Trace Center, DEC and SUN. So summarizing, we've got some stuff. In the Trace exhibit booth, we've got a SUN system with the server stuff up and running, so you can test that out. If you want to stop by and see some of these features in action, come on by.
Beth: Now does this work require any modifications to the X server or was this just all built on top of standard X.
Earl: Yes, the primary level of work was done in the DIX level, which is a device independent level. All the work for Sticky, Repeat, Slow, Bounce, and Toggle'Keys happens in the DIX layer. MouseKeys for X11R5 has a device dependent (DDX) portion. Once again, there are two basic levels of the server. There is a device independent layer where kind of everybody uses the same X and the device dependent layer which has IBM, HP, SUN, Silicon Graphics, etc. specific stuff. In the DDX, specialty features of AccessX were added to allow MouseKeys on IBM, SUN, and DEC to use extra capability. Mark has been making sure that IBM was working correctly. Will Walker, who did the primary development of the server stuff, was making sure that DEC stuff was working. Various other people with SUN. So, primarily everything was built into the DIX layer so that there was minimum modifications needed by manufacturers.
Beth: Will this software will be distributed by the vendors, not by the X Consortium?
Earl: AccessX will kind of be via the vendors. COSE members, because SUN is handling the server aspects will have all the AccessX stuff built into it. Then, when we go in the X11R6, everybody will kind of be checking the XKB stuff. Because CDE members are all using the same server, everybody will have AccessX. HP will probably have to make some modifications though.
Dan: So the X11R6 server will or will not have extensions in it?
Earl: X11R6 will have the XKB extension which has AccessX. But it is not a separate extension, it is rolled into a larger protocol.
??: How do you click a mouse button?
Earl: Maybe the best way to answer that is the usability aspect of what are available in the Macintosh and the PC world through AccessDOS, Access Pack, and Easy Access are similar for AccessX. AccessX has the same implementation of the techniques that are currently used. So the user that is coming from the MAC or the PC world doesn't have to relearn these techniques. We purposely built it that way so all new X users had to do is learn how to use the window environment, and didn't have to relearn keyboard access.
Mark: Is everybody kind of clear on this? Anybody need any further discussion on individual features themselves. Like the StickyKeys, MouseKeys?
Earl: I can also provide copies via a postscript file of the presentation we will be giving at 8:00 AM. I will make them available to the DACX alias.
Mark: I think the other thing that is important to remember, and Earl touched on it a little bit is that all this work has been done in the X11R5 server that is currently shipping out of MIT, and that all the stuff we've prototyped is being rolled into the keyboard extension which is going into X11R6, which currently is in alpha testing. So there is something of a solution now, plus there will be an X solution in the future. This stuff vendors can actually get now or get some point in the not too distant future and use on their X11R5 systems if they want. Or if they are going to be operating at X11R6, it will be built in from the XKB fashion also. As far as what goes where in the server stuff that Earl talked about or the user interface which Early is talking about, they pretty much follow what we are looking at here.
Earl: The vendors that will have access to it easily are CDE vendors which include: SUN, HP, DEC (not as a primary vendor), Novell, SCO. Eventually it will be available as a contrib, but it is not clear what the MIT is going to do or if they will take it as a patch? (for X11R5 stuff). We developed AccessX as a "contrib" with the express purpose of donating it to the MIT portion.
Mark: Any other questions?
Peter: Congratulations.
Mark: Thanks to SUN and DEC for their cooperative effort, and there is still some work to do. A real key player, who isn't here tonight, Will Walker representing DEC, also put a lot of effort into AccessX.
Mark: Next on the agenda I would like to have Beth Mynatt give us a review of what currently has been going on with the DACX GUI access subcommittee. This is going to involve some heavy technical stuff, I am led to believe, with proposals going back and forth between the X Consortium, some of which DACX has played an important role in, but really a small role for many reasons. DACX is made up of a lot of individuals, many of whom are in this room tonight, but most of us are not X Consortium members and there are some things that are not always necessarily easy for those of us who are not X Consortium members to understand. So it's been a real cooperative effort between Bob Scheifler at the MIT X Consortium, and the Xt Group which has control of all the X library stuff, and DACX that Beth is going to talk about.
Beth: This time last year at the DACX meeting, this group decided that the best way to facilitate access to the X Window System for people who are visually impaired, was to design "hooks" that would actually be in place in the Xt and Xlib libraries. Since that time, a number of things have happened. My group at Georgia Tech, working with DACX, created specifications for what these hooks should be, not only hooks for information coming out from the Xt library, but also control features for how the screen reader would control on application. We reviewed this specifications with Bob Scheifler at the X technical conference. Basically, we got a sanity check from him. We distributed this specification at the last DACX meeting which was in March, 1993, at CSUN. It was at that time that I learned I had to quickly turn around that specification to present at an April, 1993, meeting of the Xt working group. Since then, things have been really out of the DACX hand, so to speak, and into the hands of the Xt working group. Our proposal was well received, but the difficulty was that the extensions that we wanted to Xt had to be integrated into a bunch of other extensions that other groups wanted to include, drag and drop control, all sorts of customization applications, etc. So, the months between April and July were really spent integrating those needs to get and meet those requirements. At the beginning of July, a formal proposal was given by OSF to the Xt working group, for what is typically called the disability hooks and that was proposal P20 and P34. That proposal sort of remained stagnate for about two months, just because I think the Xt working group had some 40-50 proposals to work through, so it took a while for them to get to ours. The beginning of September, things started to finally heat up on the discussion. The P20 proposal has been through a number of modifications. It had some really good discussion in this group and I have been trying to monitor the Xt working group discussions. Will Walker from DEC has been helping out. Larry Cable (sp??) from SUN has also been helping out. So there has been a number of people "attuned" to the needs of screen reader access who have been monitoring this discussion and throwing their requirements and comments in. The proposal went up for a vote the beginning of last week. The voting closes tomorrow, I think. From all that I can tell it is going to pass. Usually they don't put them up for a vote until everyone is fairly happy with it. So, as far as I can tell, what I am going to present to you tonight, will pass the Xt working group and will be included in X11R6.
Beth: This work is really divided into three sections as Mark described in his email notes to the GUI access group. First, what are the hooks, what do they look like now, and how different do they look from the description I gave to you in March. The second question is how are these hooks installed by a screen reader, by an outside program. The third question is after the hooks are installed, how does the screen reader talk to the X application and back and forth, or what is the protocol for communication between these two processes.
Beth: These three issues have been dealt with in varying levels of completeness. The first, which is what are the hooks themselves, have been pretty much solidified and that is what the voting is on now. Second, which is how they are installed has been fairly well settled, but in an informal level also within the Xt working group. So I can go over a scenario of how that is being described. And third, what is the protocol for communication, is still a fairly open issue. If you got the email from Bob Scheifler, he basically gave the DACX group the go ahead to work on this and he still has hopes of getting this into X11R6. So the end of this presentation is really a "call-to-arms" for people who are interested in this to get together and work on the protocol design.
Beth: So what I am going to do, is to go through the P20 proposal as it was distributed to the GUI access group and just try to go through it step by step so everyone has a good feeling for what is involved in the hooks part. The first thing that needs to be understood is that these hooks are for notification only. When we were first talking about this in March, we were talking about controls that would allow the Xt Intrinsics to notify out to the screen reader, to tell you when things have changed in the application interface. And we also talked about having control so the screen reader could change what was going on in the application interface. For example, the screen reader could move the scroll bar for the user. What this proposal is about is ONLY information going from Xt to the screen reader. Only one way communication. How we are going to facilitate the other way is at another level. The Xt working group really wanted to divide this into two parts. These hooks are only supposed to be used by an external agent such as a screen reader program. These hooks are not supposed to be used by application programmers. That is information for us in terms of what we think is going to be changing out from under us in applications. That is why they are called "hooks" instead of "callbacks" because they are really supposed to be used by external agents only.
Earl: So that means it isolates everything in the application?.
Beth: Right, the idea is that if we are using these hooks for screen reader access, we don't have to worry about the application program pulling things out from under us, like uninstalling our hooks.
??: There is nothing that would prevent anyone from using them?
Beth: Yes, in the X world it is hard to say what prevents people from doing things. Whether it is you being told to, or that type of access not being developed. They would probably have to go in an around about way to be able to do it.
Beth: The way this works is that let's say an X application is running up in your environment and you want to attach a screen reader to it. So your screen reader would preregistered hook procedures into the Xt Intrinsic library and I will explain further on how that is done. This connection is specific to a display, so usually a display is associated with an application. It is usually a one-to-one correspondence. Two applications cannot share the same display. But an application can have two displays, allowing things get a little crazy sometimes, but most the time you can think of a one-to-one correspondence between display and application. If an application gives you two displays and frame maker is a typical example of this, it is not to hard to figure that out and deal appropriately ??. The hook procedures are executed when Xt reaches any set of notification points. So, a majority of this design is figuring out where in the Xt libraries to create notification points that call out to these hook procedures. On these notification points which divide them into five groups, create, delete, and three types of attribute types of changes. The interface for registering these hook procedures is identical to the Xt callback interface. This is nice because in the X world in general, you like things to operate in reasonably the same way. So essentially Xt is providing us with a new widget. They haven't put a name to it, so I just call it the "hook" widget. The resources of the hook widget are these hook procedures, and that is how that is going to work.
Beth: To retrieve the hook registration or to retrieve the special widget that is holding things, they've added a new call, called "XtHooksOfDisplay(dpy)". So the first thing the screen reader needs to do is find out the display that they want to work with and then they can call the XtHooksOfDisplay to get the hook widget. This widget is created after Xt display initialize, so it is created way before you have to worry about it. If you care about this, the class of this widget is an Xt private, implementation dependent, subclass of Object. It has no parent. The resources for this object are the callback list for these hook procedures and also two resources for the top level shells, and all the callback lists are initially empty. There is a bunch of discussion about whether the hook procedure should automatically be there, and they said no it will be empty to start with and it waits for a screen reader to connect to it.
Earl: Could you quickly say what is meant by Xt private, implementation independent, etc.?
Beth: Xt private is hidden into the Xt Intrinsics, this is suppose to be hidden from the application programmer.
Dan: How does a screen reader application actually get into the address space?
Beth: We are getting there. We have this hook widget. The following procedures can be used on this. (see P-20 proposal for list). This is a limited set of procedures, and they are not particularly interesting to us, as these are just generic Xt procedures. The most interesting are things like "XtAddCallBack", and other callbacks, etc. That is how you establish the hooks procedures for the screen reader. The rest of this is pretty standard. Some things have been deleted from this. One, being that nobody can destroy the hooks widget out from under you.
Dan: One thing I notice is that you have "XtCallCallBackList" So that means that if an application specifically knew about screen readers, could say call the callback list and tell it to callback something specific?
Beth: Yeah, you can do that plus there is another way that is even more direct talking to your screen reader. That is one concern that was definitely brought up in the discussion, which is if applications may want to help screen readers out or specialize widget sets or things like that building in mechanisms for doing that.
Beth: The resources are more interesting, essentially the first five resources are the callback list that are associated with the five hooks. (see P-20 proposal for Resource list). The other two resources which are read only are the top level shells associated with the display and the number of shells. This is helpful when you start up and you need to find out how many top level shells are associated with the application.
Beth: The "XtNcreateHook" callback list is called immediately from these set up points, "XtCreateWidget, XtCreateManagedWidget, XtCreatePopupShell, XtAppCreateShell," and their corresponding versions or something like that. The data that is passed is the widget that has just been created, the argument list which is a set of named values or pairs, and the argument count.
Dan: Motif has an entire parallel set of "create" things, etc.
Beth: Okay, but this discussion is at the Xt level. Essentially, those motif calls are convenience functions that call down in the Xt level.
Dan: Some of them do.
Beth: There is no way for Motif to bypass the Xt generic functions. There are just convenience functions, because nobody has to program them.
Dan: The last version of Motif, "1.something" has convenience functions that stepped around the generic functions because it was faster.
Beth: Well, remember that the OSF has been reading these specifications, looking at this to say Motif does this, Motif does that. I am not a Motif person. So that is why they (OSF) are working on that.
Greg: Even if they go around the convenience functions, it still goes through the X toolkit. If they go direct to "XtCreateManagedWidget?", or something, it will still be picked up by this.
Beth: "XtNchangeHook" has the majority of calls, things like set values, manage children, adding and removing callbacks, changing translations, doing pop-up, those sorts of things (see P-20 proposal). This is the majority of things. A lot of these things are convenience functions for Xt set values anyway. They skirt around things here alittle bit. Moving on.
Beth: The first is XtNconfigureHook. This is for geometry changes in the application. People that want to know exactly where everything is located, how the screen is, how things are changing. In contrast to this is the XtNgeometryHook which is made from these types of requests. And this is usually made from a bottom up perspective. So this is when a lower level portion of the interface is, negotiating with this parent widget saying it wants to change how big it is or something like that. This is an artifact of how Xt is implemented, just rolling over into these types of hooks. The call data is slightly different because it has three levels of certain negotiations: the request that is made by the widget itself; the reply which is essentially from some type of parent as to whether the request is to be honored; and the result which is what finally happens. For example, some particular widgets says I want to be 20 sizes larger, the parent says no you can only be 10 sizes larger and then the result is whether the original widget says okay forget it, I don't want to change size at all or okay I will accept what you say. So this is just where it really gets into a bunch of geometry stuff but this also included as far as how the application can change.
Beth: The last pair is fairly straightforward. This is just a XtNDestroyHook which is registered after phase 1 of destroy is complete.
Beth: So those are the five types of hooks that we have. The last couple of things is getting the number of shells and the shells themselves and those, again, are resources that you can query from the hooks widget. And also if you want to retrieve a list of displays associated with an application context you should use "XtGetDisplays". So that is the text of P20 itself. This is what has been officially put on the Xt working group and this is what will hopefully be officially accepted. From what I have been able to tell and from the discussions of the working group and from looking at GUI access list and other lists that people have given me things of the type of information that we need, this should provide more than enough coverage for the type of information for screen reader access. It provides a lot of other things that people need for resource editors and other types of requirements that went under here. Like I said this has been at least 2 OSF people on this group looking at this just from the perspective of Motif. So, although I am not an Motif expert, I think Motif is fairly enthusiastic about doing this. Also, every single major vendor is on this working committee as well.
Peter: Will this document be circulated again through the entire DACX.
Mark: I'll put P-20 back up on the DACX mailing list next week.
Beth: The slides that I just put up are exactly what text word-by-word that Mark distributed. The next slide has not been distributed, so if you want this information I can give this to Mark. Or I can post it myself. The next two slides talk about the installation of the hooks. How does the screen reader actually get these hooks active for access to X? And this description has come out of us talking through scenarios in the Xt working group. This isn't me coming up with this all by myself. This is from the Xt working group talking about how these hooks should work.
Beth: Basically, the consensus is that the interface to start the hooks going will be through the vendor shell. Every widget set like Athena and Motif has a vendor shell, and they are pretty "grundgy" things from what I've heard that do a lot of initialization work. But it is a convenient way for us to get toolkit independent initialization done. We already have an agreement from the Xt working group that we can work with them to modify the Athena's vendor shell for X11R6. I think we are going to be able to work with Motif to modify their vendor shell as well so we can go ahead and get things started within the X11R6 time frame.
Earl: So in OpenWindows that would be like the desk top window that comes up without any windows in it?
Beth: No, this is nothing in user sees. This is just something that is provided to the toolkits for toolkit specific initialization. It is where they stuff allot of things and that is where they decided to stuff this. But it won't be too hard to add our stuff, because we really only have to add one command, "XtAddEventHandler", which is per the display that looks for a client message which then executes the screen reader and net proc, and these are all my terminology. So, essentially in the vendor shell, all it does is look for a message from the screen reader program to do the initialization. The client message needs to contain enough information to set up the communication channel. So this is what the net proc looks like. It basically opens a socket or an "ICE" channel or something like that to set up a communication and it calls "XtAddInput" which is on that socket. You should call the "ScreenReaderListenerProc". All these steps are fairly simple.
Dan: And this is what is not there?
Beth: Almost none of this stuff is "there" there yet. All the stuff should be there in X11R6.
Dan: But there will be some thing on every application called "ScreenReaderInitProc"?
Beth: Yes, it is going to be through the vendor shell. So what we are talking is the vendor shell is going to be modified to contain this message. The "need" ?? thing is going to be called ScreenReaderInitProc and ScreenReaderListenerProc are going to be included in the library. And there will be some other procedures.
Earl: So, let me get this straight. So that's like for Motif?
Beth: Yes, Basically the vendor shells are token specific so that will be for Motif and Athena. And then, hopefully, the screen reader procedures can be transparent across other toolkits.
Earl: So this is, for example, where OSF is coming in?
Beth: Yes, OSF is helping us on modifying the vendor shell for Motif and otherwise this is still just standard vanilla Xt distribution. The only thing that is really toolkit independent (dependent ??) is the modifications of these vendor procedures, vendor shells, because that is going to be the best part to put it.
Peter: When do the vendors start seeing this? I guess most of them already have the vendor shells. And what sort of evangelization effort is going on to get them to incorporate this into their tool sets?
Beth: Basically, Athena is straight forward because that distribution goes up with the X11R6 distribution so that is that. From what I gather with the Motif distribution is this would be part of the next release of Motif. I don't know exactly how X11R6 works. I can imagine that somewhere they could already have a modified Motif vendor shell that could be out ahead of time. Again, it's fairly straight forward changes that nobody is upset about having to make so there's not that much evangelization.
Beth: Okay, this is psuedo-code for what the listener procedure looks like and basically there is just two parts of this. The first time this gets called it's going to like grab the hook widget from the display procedure that I already talked about and if the hooks haven't been installed yet or if they need to be modified, essentially it calls the Xt add callback on the hooks widget. For example, it can say Xt callback on the hooks widget for the create hook, it would install the screen reader create procedure. So essentially for all the types of hook procedures it installs screen reader procedures associated with that. Otherwise, it's listening to the socket or whatever the communication channel is and when it gets messages from the screen reader it also handles those. So, for example query tree might be a request coming from the screen reader, and it would handle that or something like set values. So this is what this looks like. Again, it is still fairly new.
Beth: So that is the line with two slides on hooks getting installed and getting all the procedures set up and things like that. So far I am talking about a library of screen reader procedures that would be included in the Xt or in the X distribution such as this listener procedure and this initialization procedure and the defining of the client message which gets everything rolling along.
Dan: This is part of the P20?
Beth: This is part of the P20 discussion. So the P-20 specification was that actual first five slides that I showed you that was fully specified. The last two slides has been out of the discussion of the people saying this is how you "use" these things.
Peter: Until we hear it though, we don't feel reassured that it is obviously going to be done.
Beth: I have members of the X Consortium that say we will modify the vendor shell to do this. I have this in full text. The point that needs to be made about this and this is due to the leadership of Bob Scheifler and others, is that the Xt working group has been fantastic about doing this, and have been highly motivated about it. They have been really nice, and to some extent a trust relationship built in to the fact they want to see this occur. If any of you know Donna Converse or Daniel Dardailler with the Xt Consortium, then you would note that those two have been the two key players in really making this happen.
Beth: The last part is on protocol design. This is where things get really fuzzy because this is basically where Bob Scheifler called the DACX group saying "if you guys want to make this happen let's do it". The Xt working group said this is too much work for us, and we will get to it in X11R7, so if you guys want to make it happen, then we will make it happen in X11R6. So this is a "call-to-arms" to you all to make this occur.
Beth: The following message was sent to DACX from Bob Scheifler two days ago. Bob stated the following:
"I won't be at the meeting so I thought I would supply my two cents worth about working toward an access protocol for the blind. Although an X Consortium mailing list was formed to work on the revision of the Editres protocol, there has been relatively little discussion or forward progress. Mostly people are too busy with higher priority tasks. There are a number of fairly difficult problems to solve in providing a high quality protocol for resource customization, that extend into making changes into Xlib and Xt, not just designing a protocol. And it gets more complicated, if you try to consider a toolkit independent protocol, for example, one that might work with both Xt and non-Xt toolkits. My guess is that these problems are pretty orthogonal to the problems that needed to be solved for disability access. Yet, there must be a lot of information that you need to extract from the application that is common to Editres and disability access. On the one hand, decoupling the two efforts could get the access protocol done sooner. On the other hand, convincing people to put support for two similar protocols into every application might be difficult. My suggestion at this stage is that you proceed as rapidly as you can with a semantic design for an access protocol, and worry a little farther downstream how it fits with Editres protocol. My guess is that the right implementation approach is to put the protocol on top of the ICE, inter-client exchange protocol, that the X Consortium is currently developing. ICE is basically a messaging/multiplexing framework over a reliable byte stream, such as COTS or TCP, supporting both synchronous and asynchronous messaging. The X Consortium is using ICE for Drag&Drop in Session Management protocols, and I would expect to use it for new Editres protocol as well. I am hoping that the ICE specification will be out for public review within a month, but if you think in terms of the TCP- based protocol directly between the application and the interface agent, not going through the X protocol, while working on the semantics of the access protocol, then factoring in ICE should be mostly a coding issue."
Beth: So translating that down. It means define an access protocol, base it on something like TCP and IP, and they are probably getting coded on top of ICE which is what I've already heard from the Xt working group. I have already requested information on that. Hopefully they will get it to us as soon as it is out for public review. But, Bob and also Donna Converse said it should be basically a very simple issue to get on top of this. The good news is this, we don't have to go through the X protocol to do this. Pretty much the X protocol is very nasty grundgy business. On a separate protocol, we can define how it looks as we want it and it should be a fairly simple issue to do. So given this, here is my start on kicking off a discussion on protocol design. Just for fun I've listed some goals. Obviously, we want this protocol to be efficient. That translates into only containing the minimal amount of information necessary. One thing that we can think about is Xt independence. I think it is already on the agenda, which is what we do when we start working with non-Xt tool kits. If we go ahead and define a protocol now that doesn't have all sorts of Xt grundgy built into it. Then porting to something like Fresco, which is a non-Xt tool kit, won't be as difficult. Since we want all of our X screen readers to be using this, having some Xt independence in there will be very nice.
Dan: Another goal might be very useful to add to that list is that it should be blindingly simple. The biggest complaint you hear anyone talk about X, is that it is too weird, too big, its like a monster. Whatever this protocol is anybody, who knows how to write C ought to be able to deal with this protocol.
Beth: I think that's another reason to try to strive for Xt independence, because as soon as you let Xt start pulling, then you start picking up all the weirdness of X itself. So if there is anything difficult about it should be on the side of translating Xt into non-Xt and then everything else should be fairly easy.
Beth: Features of TCP, for those of you who are unfamiliar with that what that tells us is that we can count on reliability, which means we don't have to worry about packets getting dropped. If Xt sends it, we receive it, or vice versa. It looks like reading or writing to a file, is one way of looking at it. Like talking connections. It is connection oriented, so Xt connects to us, we connect to them and we get guaranteed orders and we don't have to worry about packages getting messed up or out of order.
Beth: Just to start this, again, I don't want to insult anyone's intelligence on protocol design but I haven't done this very often so I figured we would start at the beginning. We need to look at the type of messages that we want, specify the senders if it's coming from Xt, coming from the screen reader, define what event initiates the message, what causes this message to be sent, define the behavior expected in the recipient so when we are expecting a reply or acknowledgement, and then actually defining the content of the fields. So I think this is the kind of stuff Bob is looking for, for a starter in terms of quickly defining the semantics. As far as the message types, again, this is my first draft of the list and I expect this to change. Messages originating from Xt: The first three I have correspond to the hooks themselves. The hooks are obviously going to create messages, so object creation, object destruction, and then I put something called attribute changes, which would encompass the set values geometry changes and configure changes. I think this is a real good chance to eliminate Xt in our protocol and just talk about attributes or resources of objects changing and not let all that Xt filter into it. Originating from the screen reader, some of the things that we've been using in our design is something like query trees, so find out the information about a widget tree, getting the top level of shells as necessary to defining the trees. Are there excessive trees associated with an application? Things like getting the specific attribute for widget. Set Attribute: This is the only thing that we have in here with a protocol that is actually causing changes in the application state. For an example, if a screen reader wants to use a scroll bar for a user, there are about two ways you can to this. You can do something like simulated mouse movement, simulated keystrokes, but that could run into some problems because depending on how fast your CPU is running, how you move the mouse could also effect how the scroll bar moves so you get some weird behavior. So it is really nice to set the resources and say move the scroll bar to this location. This is the only thing that I got the X group to say it's okay for the screen reader to make the application change. They are very concerned about having us sort of changing things out from under the applications because X could be confused. So this is the only example of that. Otherwise, X input mechanisms, like X Test will be used for simulating user input. So this is things like simulated mouse events and those sort of things that use X Test. From what I gather X Test is going to be a standard extension or integrated into X Windows itself.
Dan: There are a couple of weird things. X Test "2.something" had couple of really neat features that X was lacking, mostly stuff like in DEC X Trap ?? and ultimately allowed the user to recognize older applications. But you still have to fall back to all the protocol snooping stuff.
Beth: I hope not. Bob and I have been at each other on this since January about how to do this and he is convinced that X Test is the way to go. We have been using X Test since April.
Dan: You guys are using a proxy server.
Beth: We are using a proxy server for only one thing and that will be replaced by an Xlib call. So we are not using a proxy server to do input at all. We are using the proxy server to get text.
Dan: To get text for the application that cheats.
Beth: This was the one thing that was left off my slide. For things which cheat, we have a fail safe and that has been part of another discussion, which is why I always forget to mention it. But we also have a hook into Xlib, which is basically right at "put on wire".
Dan: That's not good enough.
Beth: No that is. It's basically protocol snooping without protocol snooping because it is right before it gets put on the protocol.
Dan: But what if the thing that is doing the writing is some ancient program, on some ancient computer that you have no control over?
Peter: The whole issue is if we are creating a wonderful brave new world, and everybody uses the brave new world, then everything is great, but, and that is very important to do, but if we are sitting here saying I am trying to write an application that I can give/sell, whatever, to the user community. The user community is sitting here with frame maker version, whatever, that came out in '91 or they have custom built apps. or user apps. that don't use our brave new world. What do you do for them? Do you just say I am sorry or?
Beth: No. There are two issues on how to do this. The first which is how to design and do it right from X11R6 and then on. And this is what this presentation is about it. The issue of what do to from X11R5 and before, which is you run something on what you guys have, which is going to have to have a pseudo-server and it is going to have to have X Trap or something like that. I don't want the design of how to do it in the future, from now on, to be contaminated by the past. It doesn't make sense. It is really an orthogonal issue, what happens to something that is X11R6 compliant and forward, or what do we do for X11R5 and before.
Dan: There isn't that much you have to break to add all kinds of functionality. There is a guy at Princeton who is working on compressing the X protocol and he had to bend over backwards to collect protocol traces. If X Trap were standard then, that would be it's curb cut. X Trap does a lot more stuff.
Beth: I have not heard anything that gives me any reason to believe that X Trap is ever going to become standard. It's considered by too many people to be too big, to be inefficient, and it's just not going to be in there. So if they say implementation on X Trap is fine, but is not going to be standard. I am not going to say whether it is right or wrong. I just know that we were told that we could base it on X Test, that was going to be standard, we couldn't base it on X Trap, if we wanted a standard solution cause it's not going to be. I am just telling you what they told me.
Beth: Alright, message types: Others are fairly simple, things like get the toolkit vendors, you want to find out if you are dealing with the Motif application or Athena application. Activator and deactivating hooks. This we should probably put in there because I know other users in this protocol will definitely want that and getting displays stuff like that and then the replies for that. So again this is the starter list for the messages for the protocol. I don't know if we really need this.
Beth: This next overhead is sort of an example of how things might start up. Screen reader starts stuff off by sending a client message event through the vendor shell and the initialization for the hooks getting installed, the socket gets open and connected, the screen reader accepts the connection. Probably the next thing it wants to do is get the toolkit vendor. If I am working with the Motif application, it gets a reply back from that. It gets the top level shells for the application. Gets that reply and probably does a few rounds of the query tree per a top level shell to find out the current stage of the application. So this is important. This is one of the nice things about not basing on a pseudo-server is that you can do something like this. The application can already be running and you can attach the screen reader to it. To use a pseudo-server you have to start describing it first. It is a big limitation. It keeps somebody from walking down the hallway and someone saying I want you to look at this and says sure and attaches a screen reader to it. So that is one of the good benefits of getting the hooks. The rest of this stuff is fairly straightforward things like object creation, object destruction after change called message gets into the screen reader. Interesting to note that the screen reader set attribute, you get an acknowledgement back because you are going to get the attribute change information. And if you do set attributes, you are going to get the set attribute reply.
Peter: This seems like a lot of X geometry issues. I can do a set attribute and that attribute might fail. The scroll bar has 0-100 and I say set it to 150.
Beth: That is another reason why they are queasy about letting us do set attributes. There is another thing that is different. We, for example, get attribute reply or the attribute change, ?? we lump all that together. Some things are resources that are meant to be set, while some things are just sort of fit into a "half" resources. There is a lot of other stuff that we really shouldn't be setting. So if nothing else, this is the warning to the screen reader community which is you know you can kill yourself by not being careful and not finding out what the limits of the scroll bar are and where you try to set it. But at least gives us killing ourselves versus somebody else killing us.
Peter: Although, if we are designing this protocol we can maybe also build that in. So if I do a set when it comes back you can look at that.
Beth: To do that kind of sanity check might be more stable.
Earl: Set attributes is the only one that can modify the application?
Beth: That attribute is the only thing that modifies the application.
Beth: We wanted things like simulating, select and all that kind of stuff.
Beth: So this is fairly simple stuff and the last stage is actually defining the content of the packet. Interesting thing to note here like for object creation, what we are going to get from the hook is the ID widget and the key value pairs. What we might want Xt to do for us is also to add in the parent, class, or the name those sort of things. This is something we can also define which is, do we want a query, because when we are in the address base of the X application, do we want a query for it to mention that in the packet?
Peter: Probably.
Beth: We probably do. I did the easy ones. As an exercise to the group to do the hard ones.
Peter: You don't expect us to finish the protocol in the next hour?
Beth: In closing, an advertisement for those of you who are morning people and want to go to the talk (8:00 AM presentation), I will be talking about Mercator from an interface perspective. What may be more interesting to you is that I actually have a demo for Mercator running in the Trace booth. I will be there tomorrow directly after the talk and for a little while in the afternoon. The Mercator version is a hodge-podge of the concepts that have been talked about already. Which means it uses our prototype version of this type of protocol and these types of hooks so it's got all that. It also has the psuedo-server sitting in there because we don't have the Xlib hook in there, so we are using that only for text and we are also using the X Test mechanism for screen reader use. Two out of three parts of Mercator are using what I've described and we just haven't put in the last part.
Peter: I would like to add that in addition to defining this protocol for toolkits, for doing it the right way. You might want to also either give thought to or schedule on some agenda an idea of an application base protocol. There is an effort underway right now for access aware on the Macintosh. Similar effort underway with Microsoft Windows.
Peter: There are going to be questions ?? asked to do strange things under X. Frame is the one that comes to mind. At some point we are going to want to say, alright, you are not going to do it the right way. You don't believe the X font mechanism is good enough even in X11R6 so you are going to generate it yourself. We understand that, because you have a market presence, so here, tell us what you are doing, here's the protocol to use. That is what we will want to look at and think about. A lot of protocol here you just sort of lift out, put a slightly different API on, and check the library of vendors to use.
Dan: Quick question. You mentioned P20 and P something else?
Beth: P34. P34 got removed. P34 was another set called the hook widget. Before they use to have something called the screen object or display object which was what they called the first class widget object that would use this type of functionality. The discussion went into this horrible cycle of defining this. Bob Scheifler was going to call it the "all mighty-does everything object". So they went for a much more minimal approach which was this sort of Xt private hidden, application writers aren't suppose to touch it. All that got incorporated into P20.
Earl: What are we going to do next and what type of timeline are we going to put on it. We don't have to wait six months here now are we?
Mark: We don't have six months to wait from Bob's indication.
Beth: The schedule for the protocol design should be really like week 1 we want this done, week 2 we want this done by then. I would think that in less than 2 weeks we could give our version to Bob for a sanity check. Because the X11R6 alpha has already gone out, right?
Peter: Is there anyway that non-X consortium members can look at the output interface?
Beth: I am not sure. Basically, the protocol design is suppose to be DACX work. The only thing that was not in P20 was the step about installing hooks stuff like that.
Dan: ?? the initialization process and about getting data back and forth?
Beth: We are really suppose to worry about the third part. I don't think we are even supposed to define what the contents look like that starts every thing up. From then on is what we are suppose to do and I got the go ahead to meet with the working group and from the Georgia Tech group to have everyone to work on modifying vendor shell. So we will be doing that.
Earl: So it looks like you defined kind of an outline. There may be some missing components but the major portion of the outline looks ready to proceed. Have you thought about what is the next step in your mind, who do you need to work with, who should be doing this?
Beth: What I am looking for is volunteers in helping to define the semantics, figuring that out is going to be the GUI group.
Mark: That's my question. Do people feel comfortable who are on the GUI access group that this is a GUI group activity and that the e-mail which has been suspiciously quiet over the past several months is going to burn some smoke on the system I have at Trace or should we set up a special group. How do people not feel?
Peter: It seems to me that is definitely a GUI access subcommittee activity. If there is somebody on the GUI list that doesn't want it, fine. Anyone who isn't on the GUI list who wants to work on it should be on the GUI list.
Mark: That's an important point, because that will be a method of communication, the broadcast address, and you all have every one else's address at this point if you don't e- mail me and I will get them to you.
Peter: He's not on (referring to Dan).
Mark: We'll take care of that.
Beth: One of the reasons I was asking Greg Pike if he had time because I would like to see someone on the GUI group saying that was their activity, because I am putting full effort making sure that P20 finally goes through and worrying about modifications to the vendor shell. I am definitely willing to help in protocol parts, but we are probably all safer if it is not my full responsibility to make sure I have those. I would like to see someone else being the primary core for that. I would be happy to take what we've done with this group. So I am happy to be sort be the liaison to the Xt working group, but I would like somebody to be the point person within DACX. That is the specific "call-to-arms" to take this big promise and happen quickly.
Mark: What we are talking about now is a focal point and someone to do the major review and we are going to keep the contact to Xt through Beth. I don't know if that helps define the workload any. I am perfectly willing to give you as much help as I can from Trace. But some of this stuff, I will be honest with you went right over my head. There might be some other resources Jim C., down at Austin, who might want be involved too. You might wish to give that some thought. But we need one point person.
Beth: This isn't the hardest task in the world. I just need someone besides me.
Jim C.: I am not sure what you are asking. Someone to work up the definitions to some of these things in detail or someone to act as an administrator.
Beth: I am asking someone to be the focal point for defining the protocol. Someone that is going to be willing to send nasty mail to move things along.
Gregg: We need a project manager.
Mark: Someone is going to collect it all.
Gregg: Make sure it happens.
Greg: I am kind of in a difficult position. I don't know if I can really say yes or no to this right now.
Peter: I can promise you that you are going to get tons and tons of help from us, but one of our products will be out in two months, so we can't take on anything more.
Beth: I know Will has already taken a large leadership responsibility.
Mark: Will mentioned that we might get some more help out of DEC.
Beth: I think we will get help out of Will, but I just don't think we can say that.
Earl: What do you think Mike?
Mike: I know Will is trying to work with some other folks but I don't know how much time that will take. Probably will be best not to say anything.
Mark: I can work with Greg between now and when Will gets back from his trip.
Jim T.: How large is the GUI membership of this group?
Mark: We are talking Berkeley Systems, Georgia Tech, IBM, 5 to 8 active participants, but also members from Bellcore, Bell Atlantic, some consumers, etc.
Jim T.: The reason I am asking that question is I understand why Greg is saying I don't know if I can take this on. So I would like to understand better what the question is. Maybe the five of you and I should sit down and decide and if that is a good thing to do?
Beth: For right now, it's appropriate to realize that this question is out there and go on with the regular meeting.
Gregg: In essence, all of the efforts that we have been talking about go for naught without the protocol and so it has to happen. There is a group of highly motivated people to do things, but we need somebody who is highly motivated and not distracted, or who will promise to be focused enough for a few months to begin to get this thing pulled together. When you are done you are talking about a document that is how many pages long that would define it the protocol? We are not talking about a mega document, it's just the matter of following around and making sure and following up to make sure that it does in fact happen and we don't have a lot of candidates. We don't need to put so much pressure on Greg.
Greg: Well, there is also paper workload on me I have users on IBM who are using two different screen readers who are calling me all the time and all that stuff. I think this is a small enough thing to be worked in between midnight and 2 a.m!
Beth: Those people who know me know that I would love to say sure I'll do this too. But I am already looking over the other two cards and it is safer to have someone else.
Mark: So we have the GUI people meeting right after this and we will make a plan. Anyone else want to contribute ideas to the direction of where the GUI group is going to be taking this. You are all welcome to contribute. Just because you have not been on the GUI group, there has been a lot of good information discussed here tonight, presented to you. You are all more than welcome to contribute. Many of you I see out in the group are on the DACX email.
Gregg: You will be taking key items off the GUI and tossing them on to DACX so people can follow without having get on the DACX GUI group and that will take care of that. So if you don't want to follow detail, you can sit on the DACX and still get information. But if you want to follow in indepth, you can get on the GUI as well.
Peter: All agreed, GUI access group is going to meet afterwards.
Mark: Meet or set another meeting time.
Mark: Moving on with the agenda then, item 4B1 we were going to have some discussion concerning the protocol and semantic information of Xt. I am assuming that Beth has pretty much covered that so we can skip over that point. Agenda item 4B2 we were going to have some discussions concerning OSF and I apologize for making this agenda as brief as it was, but this is a tentative agenda. What this item was intended to do, was allow a new member with us tonight, Mr. Peter Duran, who is in the back of the room, time to discuss some of the work he has been doing out at Art's Computer Products Inc. concerning his work with OSF. So I will turn this discussion over to you, Peter.
Peter D.: I have been working with the OSF system now for about a 1 1/2 years. I coming from kind of the opposite end from where Beth is coming from. Beth is doing all the details, most of which I don't understand. It is really a political/educational problem rather than a technical one. People who wrote X, people who wrote Motif or Windows are clearly quite capable of fixing it. The question is getting them to be willing to do so, how to force them to do so. As it turns out in the case of OSF, I met with their professional associates group, a year ago in June and they said what the hell is the ADA! They had no clue and weren't really sure they wanted to deal with access issues at all. So "what to do" was a topic of conversation in the next year or so to convince them that it was a disability community interest that Motif should be made accessible and that it would be in their financial interest, because they are becoming a cost making corporation, rather than a non- profit. Revenue thing is what they are concerned about. To make a long story short, I have been meeting with Rich Martin, who is the director of the professional services group at OSF. The story is that they didn't have such professional services before, so they created one to deal with it, and they are more than ready and willing to do whatever it takes to get Motif to be accessible if someone is willing to pay for it. OSF and Arts' have several proposals floating out there with very major corporations to fund the second project ?? and several people from those OSF people have been involved with the X people to try and coordinate things. The reason I tried to go the Motif route, in order to worry about Motif and not about Galaxy ?? (sp??), Openlook, etc., is being in the business world, you have to know what the state of awareness is ??, where the demand is and that tells us if they want to pay for it. I would say that at least once a week nowadays my company gets a request from a major company saying, "How can we possibly make Motif accessible?", or these applications because all of the RFPs keep coming out of Washington demand total access. Motif was the focal point of this business in the federal government community. So we've had a sort of an educational campaign going on. I am convinced that the Motif people are really quite serious about doing a job, getting large print, getting speech in, etc. They are not sure exactly how to do it yet, but they believe it doable within about a year, maybe a bit longer and they have committed to put it into Motif 2.0 or 2.1, depending on how long things take in the timeframe. If people really like it, they will make it a part of the Motif ?? and carry it forward throughout all its revisions.
Peter: It seems to me that we have not encountered any problems in our dealings with the X Consortium, Motif people, etc. in terms of wanting to do it. They want to do it. There doesn't seem to be any need to convince them. We have gone through talking with ?? and engineers, and it's getting done.
Peter D.: That was my point though. By no means clear that the business decision makers at OSF are decided to go forward, are willing to do it. Rich Martin and I still are not sure. And when we had a meeting in June at Motif, we didn't get firm commitment even at that point, from their business, people whether this is a high enough priority versus doing something rather for the Japanese which brings in bucks. So, yes the technical people are ready, willing, and able but it is not clear if the upper level of management want to, even at this point, and time to take it on as a major business activity.
Peter: If you go through the upper management, it may eventually get done five years later completely different. It is already going in. We have been working on this for a year and a half now and it is going in.
Gregg: There is also coming off of that, I think Peter, what you've been doing may help with this and that is that if you get the stuff built in and then you take it up and let the people at the top brag about it, you then are in a better position to try and get support or maintain support for what you do over time. The hardest part is the point that was pointed out and this is to get upper management to decide to do something.
Peter D.: Hardest part right now is David Brooks and Zona's ?? time, to actually devote it. The big issue in June, when I had this meeting with all their people, they had head ones from DEC ?? all the way up to the top. Where do we pull the new people on board to get developed more or we take our Motif people and have them work on this opportunity and that still hasn't been decided as of a week ago. My feeling was upper management was probably going to hire more people to work on a some other project because their feeling right now, is that they will come up with a special version of Motif 2.0 for the disabled community. With the special things that need to change and see how well it flies. Then retrofit Motif 2.1, with the ones that work and leave the ones out that fail.
Beth: I have a couple concerns with this mainly because I have been working with the folks from the OSF and the Xt working group. The first question is understanding which portion of OSF have been working on this. When Mark distributed your proposal to the DACX group, I sent a memo to the OSF people that I've been working with saying, hey it looks like we have two separate efforts going on, how is all this integrated together. The response that confused me is that they said well this isn't anything that we are working on, we haven't heard of this. And then the second thing that I did was find out what professional services was and understanding how that functions within OSF, and the answer that I got to that was that OSF professional services is essentially the contracting arm of OSF. What that means is that they are contractors for hire, generally for use of providing very complicated Motif applications that need very specific help with understanding Motif. But they are not part of the standards body essentially of OSF. They are not part of the decision body that says what Motif will be, which is what the OSF people who have been on the Xt working group are. So my concern is that this effort group was that the professional services will do just what you said. If you pay a lot of money, you can create a special version of Motif but it has nothing to do with the generic version of Motif, which is what we need to have underlying changes into so that Motif applications are accessible. Having special Motif doesn't buy you a thing.
Peter D.: Everything you said is exactly right, but the piece that is missing is that the upper level management of Motif, OSF doesn't want to really build this stuff into standard versions of Motif until they have a trial run through professional services.
Peter: If you make a few small architectural changes at the same time you are making tons of other sweeping architectural changes, it costs you almost nothing in terms of man power, in terms of resources. When you make those changes, it goes into every version of OSF. It doesn't just go into the special disability version that one particular company buys, it goes into the version schools, it goes into the versions that are in the libraries, etc. and that is what this body has been doing, and is doing.
Peter D.: But the Motif developers are not to convinced at all that a few line changes here and there are going to be enough. They are not sure exactly what changes might have to be in.
Peter: You said they haven't even looked at this yet.
Peter D.: They have looked at it in some detail and figured out at least a three to four month feasibility study depends on how complicated they think problems might really be.
Beth: One other concern that needs to be addressed is that due to the COSE and what is happening in the industry is that OSF and Motif in the future are no longer synonymous. OSF is no longer the owner of the Motif specifications. Right now OSF happens to be the only vendor in the Motif, but my guess is, knowing how capitalism works, we are going to see other vendors of Motifs toolkit because the specification is now owned by the X Open body. It is no longer owned by OSF. So that is another concern with saying we want changes to the Motif widget set via OSF because then you have to worry about Motif vendor A, Motif vendor B which is going to come along. That is why I think it is more important that we work at the X Consortium level and work on generic protocols that are much easier ported into somebody else's version of Motif and then things like Fresco and other things that we are going to have deal with.
Peter D.: Well some technical concerns that what you really want to do or get can't really be done as easily as doing it at a higher level. In fact, a guy I was talking to at Motif was not really sure that the right place is X ??.
Peter: At Berkeley systems, we have a prototype that works. Mercator is a prototype that works. It works using the existing set of standards ?? that are going into the X. So we are quite a bit further along when it comes to feasibility studies. I know that stuff gets the information. If you build it in only at the higher level, then you only get it at one particular version of one particular higher level and I think most of us think that is not enough.
Peter D.: I am not convinced that holds true, neither are the people at Motif. It is not clear how to handle all the hard command buttons, and so forth without re-inventing the wheel. That is a big concern.
Peter: We handle all that. That is what this protocol that Beth just presented.
Dan: The whole point of this protocol is exactly capable of handling that and also it isn't like there is one hierarchy.
Alan: I would like to ask a question. This is my first time here. What I've heard tonight is that people are saying that working through the X Consortium, the hooks and very soon the protocol, to make it easier to sit down and write my own screen reader and install it in any X application. What is not there is the screen reader. What will not be there with X as it is shipped or Motif as a ship unless somebody like Beth can give yours to them to ship with it, is the screen reader. What's there are the tools so that screen readers can function.
Beth: Yes.
Alan: And what I thought I heard this gentleman say is that he wants Motif to have imbedded in it the screen reader.
Peter: But he is not getting Motif.
Alan: It is going to be a mute point because there is going to be at least a half dozen screen readers there before OSF would ever get around to looking.
Peter D.: No. The screen reader would not be imbedded in Motif. What Motif developers would do is change all the things, including creating a database which is how the screen reader this is a button, so forth. This all can be done with a tremendous amount of effort and time to do it, but you really will be doing a lot of functionality.
Alan: I don't know about Beth's application, at what level it is written. But when I saw it in the Trace booth today it was running in Motif.
Beth: Athena.
Alan: Sorry, but it is real close.
Beth: The point is it operates at the widget level. It operates in terms of buttons, scrollbars, etc. Just because you are going at the lower level, doesn't mean you are talking about the higher level semantics. It is just a generic way to get to it instead of modifying the button widget, instead of modifying that widget, etc. What we have is a generic way to find out when any widget is created, when any resource of any widget has changed, that is the same thing you can get by modifying the widget set itself. What we have done is modify the generic way so we don't have to worry about Motif, Athena, or whatever changing from out from underneath it.
Peter: The whole point is to preempt the need to change individual versions of individual widget sets, is to get them all in one fell scoop and that is what is happening here.
Peter D.: At least that is what is suppose to be happening here. I will repeat myself, a lot of the developers of this stuff aren't convinced that solution is necessarily the best one. Or the most practical, financially, or time wise.
Mark: Thank you Peter.
Mark: Moving on in the agenda, one of the things was brought up by an individual in DACX is that there has been a large effort by the UNIX group, 75 plus vendors are getting together on what they call Spec 1170, which is a common set of API's within the UNIX community. My understanding, and those of you who know about this can correct me, is that when people pass this Spec 1170, they can qualify themselves or stamp UNIX on their machine. This is part of X Open again also. The concern was raised with this large group of UNIX vendors doing something in commonalty with the APIs, should DACX take a look at perhaps trying to develop some accessibility APIs with this group, I believe, might be the issue or should we be involved in it at all, or what level of involvement do people think that the DACX group should get going on this.
Beth: One of the idealistic goals of X is that changes are suppose to be OS independent. Most of this stuff that we are talking about is incorporated at the X level is the hope of being independent of OS. I know as far as the GUI stuff, in it is something that would not effect limitation of the screen reader too much. On nice thing that would happen is that right now under the API ruling on audio, audio is not really considered a first class object. As soon as speech goes on to the desk top more, having audio as their standard would also be nice. That is the hardest thing now. If people ask me how to hard is it to import Mercator from the SUN to the IBM, everything is pretty easy except for audio. So given that we worry about audio more than others, that would be an idea.
Dan: I think most of the X Open stuff. I mean they are probably going to make a sweeping declaration that is we standardize on X. As long as we can get swept in under that giant sweeping declaration that is about all that is really necessary.
Peter: Do you need to do anything to make sure that happens.
Dan: Presumably all standards evolve.
Beth: They have already standardized on Motif.
Beth: This is all part of X, so this is just X Open dealing with another layer. X Open is going to be the most powerful thing. This same standard's body has already chosen Motif. So this is just them standardizing on the OS level. So we have already swept into what they have already chosen as far as the windowing system goes.
Peter: Of course, I think it is more along the lines of UNIX may be possibly or all coming together to some common base. I think that are focus has been GUI and UNIX isn't really GUI. May be that is not appropriate for this group although there might be a bunch of common members of this group and some other group that might form under Trace At this point, it seems to me that windowing systems are where everything is going and UNIX may be a standard operating system that runs a lot of windowing systems, like X or something Windows NT like.
Mark: There sounds like there is some interest in it, but what I would like to ask the group as I am only one set of ears and eyes. There are a lot of extra interest in this group concerning access. As people see these things go across the paper/net/magazines, please copy them. Notice me somehow, e-mail and I will rebroadcast to the group. At least we can keep everyone aware of it. I think it is something DACX needs to keep an eye on.
Gregg: May be what we might do is set up a separate list address for the UNIX and then we can cross-pollinate some of the discussion. But if people are interested in doing that, I think I agree with the comments that rather than taking DACX and sort of sticking related issues in it, there is probably going to be some clean-up that needs to be done on DACX for some long period of time in maintenance and follow along and we ought to keep the discussion within it focused on that, and we can always set up another address over and people can drop in and out of that one if they are interested. One of the other questions that someone raised and I will toss up here. The question someone raised, boot- up, sign-on, log-in issues around X Windows before you get to X Windows, you've got to go through some sign-ons and one of the issues about access before you get up and running so you can load in your GUI screen reader and I don't know what those issues are, but I remember back in our early meetings we sort of said well let's ignore those for now and solve the rest of the problem. Well, may be at some point we need to go back around and solve the problem of somebody who has to reboot and can't get to their access software because they are stopped short of it.
Dan: I guess the program that pops up that says please type your log-in is a thing called XDM and XDM is something that is probably being re-written in X11R6 because nobody seems to really like it. It's got all kinds of configurability stuff, it has some scripts and it would be possible to imagine XDM configured specifically for a user who needs access. When XDM starts up, have it start the screen reader up. They had a hack running at Berkeley which automatically ran something that would change the screen background all the time. So you can make things happen before the user logs in if you really want to.
Beth: That's not a standard program.
Dan: XDM is everywhere.
Mark: It may be everywhere but I don't know if everybody uses it.
Peter: It's not standard necessarily.
Beth: I think somewhere within X Open, somewhere with COSE underneath X, but above the OSF we are talking about. People are talking about standardizing what the desk top is like and that is also like the huge standard stuff that is going on. That is probably what we want to get into, which is, what is the desk top like? I think it will include the issues as logging in and getting your environment going. How do we provide access to the root like environment.
Peter: I think at some level we have to say is this the sort of thing that needs to be in every version of X or like CloseView on the Macintosh, is this something available at every version of X and an individual user will decide.
Gregg: You mean you build your sign-on?
Peter: What I am saying is, here I am, I have an X station at my machine.
Gregg: Here I am, I just walked into my university's laboratory and I want to log-in.
Peter: What I am saying. Here I am, I got my own machine, I want to change what the log-in looks like, whatever. I can do it. I don't expect to make my machine accessible to everybody. I might not have StickyKeys installed, etc.
Beth: Your question is what do all the university labs look like?
Peter: The line I'm trying to draw is should the effort be on modifying a defaults log-in system as opposed to the harder problem of getting into every logging system that exists anywhere. Not just the default one that the public universities ought to use. Do you see my distinction?
Gregg: Yeah, I think basically the approach that we all generally used is you go to the most general that you can practically achieve at this time and then you go after the most general that you can work toward achieving next and that is kind of the strategy we've gotten. This has been a wonderful opportunity with the cooperation with Bob and the X Consortium, to not have to go through and do a patch job first and then build in later. The question has to just do with UNIX and what some of the sign-ins, and what we really don't want to do is to say the building is accessible but it's just the doors that are not! Okay. So that is one of the issues as we get into it and you say just assume everybody starts inside the building. You say great, wonderful accessible building. So I am just worried about the doorways getting in and if it requires that you install a screen reader well, then you are not talking about somebody walking up to a public system.
Peter: Here's the standard door. It is really easy to put it in, please use it and here is some legislation to backup that strongly "suggests" that you use it, and sell it through university that is public of course, would have to have it, etc. That might be.
Mark: About the last couple items on the agenda. There was some interest for people, if there is anybody in the DACX group who are actually right now currently alpha testing Motif v2.0. If they would like to get together and provide comments, Will Walker at Digital is willing to accept those comments and try to get some stuff back to Motif which may be totally non-accessible related. It has to do with look and appearance and just making Motif easier for everyone to program. Slightly outside of the group here, but some of you might be currently working with that. He just wanted me to pass it around to everyone. We've seen some interesting things in developing the client interface for AccessX, shortcomings for Motif.
Beth: The idea for Mercator is that we report to Motif in January, so I think we will have some interesting feedback also.
Mark: The comment from Will was that, in fact, it does help and he would like to collect up a list of things which he feels are shortcomings for everyone. When you guys write your interfaces for your screen readers, you are going to bump into these issues. I am sure. So, here is a chance to take a jump start from that process too. Not necessary accessibility related.
Mark: Will is willing to collect the ideas, so you can direct them to Will or give them to me and I will get them to Will. He felt that he could convince the people at Motif or OSF to try to work around the problems if we get them early enough into the alpha testing.
Earl: Can you be pro-active in contacting Will and have him place the shortcomings that he's identified on.
Mark: Sure
Earl: At least the AccessX related ones.
Mark: The last thing on the agenda had to do with some of the object oriented toolkits. I think we've "toolkitted" ourselves out tonight. I am willing to let that one fall to the next meeting.
Mark: Did everyone sign the attendance sheet? The last thing on the agenda is to always try to set the next meeting date and time. Any suggestions?
Group: CSUN!
Mark: It sounds like we are going to be meeting at CSUN, in March, 1994. I would like to thank you all for your patience and the fact that you felt that this meeting was more important than the Mall of America bus trip!
Attendance List:
Mark Novak, Trace R&D Center
Gregg Vanderheiden, Trace R&D Center (Gregg)
Bill Barry, Oregon State University
Dan Comden, University of Washington
Eric Bergman, SunSoft Inc.
Ben Drees, BSI
Peter Korn, BSI (Peter)
Dan Wallach, Princeton University
Beth Mynatt, GA Tech.
Jim Thatcher, IBM (Jim T.)
Jim Caldwell, IBM (Jim C.)
Brenda Saxon, IBM
Greg Pike, IBM (Greg)
Cathy Laws, IBM
Kuo-Ping Yung, Johns Hopkins University
Mike Paciello, DEC
Greg Lowney, Microsoft
George Kerscher, Recording for the Blind
Earl Johnson, SUN Microsystems
Paul Fontaine, GSA Clearinghouse
Peter Duran, Arts Computer Products Inc. (Peter D.)
Alan Edwards, UNISYS
Curtis D. Chong, IDS