To all readers:
The following notes were transcribed from a tape recorded during this meeting. We apologize for any mis- representation of comments.
Mark
------------------------
Universal Disability Infrared Link Protocol Meeting Thursday, October 19, 1995, 7:00 to 8:30 pm, Radisson South Hotel, Minneapolis, MN at the 1995 Closing The Gap Conference
Mark: Background information for everyone, this is the third time that this group has gotten together. The goal is to become a working group, and to work towards the development of a standard in the area of IR access to information systems. For tonight's meeting, we will work from some handouts, and talk through some things for general information until we get down to part V of the handout. At that point, we are actually going to try to talk a little bit about an IR protocol. This in an informal meeting, so if you have questions, ideas, concerns, just jump in.
We will discuss the IR project started this past spring, and I will go through a couple of goals of the Universal Disability IR Link project to get things started. The first goal is to work towards the development of a bi-directional link where by individuals with disabilities can both locate and interact with electronic communication or information systems. The second goal is to establish different types of guidelines for work towards the standardization of protocol that could be used in this area. What we are proposing to do is to piggy back off of some of the things that are going on in industry. The largest push in industry is by a group called the Infrared Data Association or IrDA. They are actually establishing the use of IR for many things, including file transfer between different types of electronic systems and networking. We see that as a very good backbone, if you will, to try and piggy back off for disability access. IrDA does all of the handshaking, locating, and hardware support. The third goal is, while we are working towards standards, and working on this bi- directional link, we have to keep in mind that we have to work closely with all of the developers of the different products. We'll have to both advocate and work with the developers of disability products with specialized access devices, as well as work with the banking systems, the building directory systems, and the people who are making the kiosks and the ATMs. We must try to draw everything together on both ends of the spectrum.
Those are the three general goals of what the Universal Disability Infrared Link is all about. For our purpose of meeting here tonight, however, we would like to concentrate on one area. You may see the use of IR or wireless radio frequency (RF) as having two distinct purposes. The first would be to find or locate the device which you want to interact with, and the second, once you have located it, to start interacting with it. We want to separate those, at least for tonight's meeting, so we can get a more concentrated effort when working on the interaction section. We are going to leave behind the location, the navigation, and the finding of the ATM. We will therefore set aside, for example, if you are a blind individual going into a building and you want to query where the ATMs are. We are going to look specifically at, once we found the device we want to talk to and now interact with it. If we have time later, we can come back to the actions leading up to the interaction. I think there is quite a bit to be done just in the interaction itself; so therefore, tonight we just want to concentrate on the interaction area.
First, I will try to get you thinking of some of the different devices which we have listed as far as things that this Universal Disability Infrared Link might tend to access. Under #3 of your handout is a list of different products. We'll just walk through them and you may want to expand this list or throw some in that you are familiar with. ATMs are at the top of the list, as well as information kiosks and building directories. There is a lot of work in several locations in the country right now for testing TV set top boxes. We've also seen things in the area of bus stops. With electronic interactive bus stops, you can query what stop you are at, what stop you want to "get on or off at", what times the bus is coming to that stop, and all types of ticket fare machines you might want to interact with. Electronic touchscreen, and especially touchscreen based home appliances, as well as office appliances. Touchscreens that might be able to interact with an IR link are showing up very rapidly in what we call the information or screen based telephones. Can anyone think of anything else you want to add?
Gregg: Point of Sale (POS)
Neil: Conference room, electronic blackboard
Gregg: With the Universal Disability Link, what we are talking about are things that are out there that a person with a physical disability can't control and with which they could use their augmentative device instead of the interface on the device. So, wireless IR is being used for file transfer, line connections, and things. I am trying to think of things which people would like to have an IR link on, that would then allow them control if they can't control them today. One of them which just struck me is home environmental controls and security.
?: Do you mean both of them or do you think that both of them are very much the same?
Neil: Security systems are installed in buildings that don't have environmental controls.
?: I have a question about the overall perspective. Are you talking about devices? First of all, there is IrDA and that is already defined as where it applies, and it has protocols, right?
Gregg: It is defined as to where it applies. They have some protocols for some applications.
?: But isn't it basically used on a table surface, and isn't it in close proximity to a computer, isn't that where it is used?
Mark: IrDA doesn't necessarily have to be limited to a computer, for example, a PDA talking to a fax machine without a computer being in between at all.
?: The list you have under #3, is that a wish list or is there already IR capacity in those products?
Gregg: In some of these we expect that there will be other non-disability motivations. For example, with ATMs, people who have little pocket electronic checkbooks could actually go up to an ATM and it would communicate with the bank and balance their checkbook for them on the spot. So anyone could go up to the ATM, punch in their code, and it would give them the correct balance of their checkbook.
?: There are already indications that is being done?
Gregg: There are indications that they want to head in those directions. With other things, like set top boxes, there are motivations from the standpoint of using the set top box to buy things. One of the things you can do is buy software, and if you do that, it would be nice if it could just deliver the software to your computer right out of the set top box. So an IR link would allow you to literally download.
?: Okay, I had to think that through for a second and consider all the possibilities.
Gregg: For other things like bus stops, fare machines, information kiosks, and building directories, there is concern that they are inaccessible. One of the ways of making them accessible would be to add the IR link. Many of these things are based on PC technologies. Due to some market courses, it is unlikely that there will be very many, or any PCs manufactured six months or nine months from now that won't have IR built into them. So when they are building a lot of these systems, the IR capabilities are going to just be standard. When you make an information kiosk, you make it by dropping a PC inside and you already have IR link capability, it is just a matter of lifting the diode and sticking it out a window. With the accessibility pressure in ADA, access may be reduced to moving the diode so that it points out the window, which would be nice. Even if you have to build in IrDA, it is going to be pretty inexpensive.
?: Actually you will have to point the whole transceiver out the window.
Gregg: Yes, the LED and sensor. The nice things about it is that if people are, for example, deaf-blind, you will never be able to build Braille displays into everything around. If you stick this little $4 worth of circuitry into the kiosk, even if a person is deaf-blind, with a small dynamic Braille system, they would be able to interact with these things, and that is a stunning capability.
?: The ADA probably isn't going to bring the pressure about to do that, but could it be inherently there already?
Neil: The capabilities are going to be inherently there, but the products may get produced without any software protocols. The model that is going into this is a file master slate model which doesn't give you control of the other machine, which is an urgent issue. Having this other protocol available connects you to the front of the machine rather than to the file transfer, so it goes in parallel. One moment you are using it to control the machine, and the next moment you are using it to do a file transfer through the same IR.
?: What works against having that happening?
Gregg: There are two reasons, both of which deals with security. One of them is that you want to set up some secure communication. If you are going to be able to exchange any kind of information, you don't want anybody to be able to sit across the street with an IR probe and essentially look over your shoulder, without you knowing that they are doing it. Today, if you are in a wheelchair using an ATM, the person standing behind you can see everything you do but at least you know that they can see and you can try to do something about it. So that is basically an IR link security, and it is a pretty simple thing to deal with. But the second reason is that any time you allow someone to connect a computer into an ATM, they get worried about if you can drive it fast enough, or if you can do something that will confuse it, or do something that you couldn't do on a regular keyboard.
Neil: I have been doing keyboard simulations where you have typical functions, like anyone else who is dealing with the front panel. When you do that, you are not giving the person any advantages regarding access to the front panel, and I believe that's from the first person I talked with about the design of ATMs. For security reasons, they said they have protocols where they use a split pin number. You have half the pin number, the system has the other half, and it gets changed during every part of the transaction. Essentially, you finish a transaction and it tells you next time you talk to me, use this number. It is possible that anyone recording the message can come up and try to duplicate.
Gregg: There is even a software were you can run a program and it will give you two numbers, two keys, and I can transmit one to you. If the key is 18795638, for example, you then use that to encode a message to me and I can detail it, but nobody else can because they don't have this second key that I have. So when you send me the message, you send me the second half of the key and now we have this double encrypted, and we can carry a conversation back and forth and only we can understand it. The next time we talk, we generate a new pair, you generate a new pair, we exchange them and we carry on another conversation. So literally, if somebody eavesdrops on you twice, they are no further ahead than the first time. If your conversations aren't very long, which they typically aren't, it is almost impossible to break a code because you don't have any length, either. So this is public domain software which is very easy to set up and keep secure. What people do worry about, Neil, is if you give me the ability to have my computer drive your keyboard and if it does nothing more than a keyboard that I can do things on, but that any human could not do because I can type fast. What you can do to prevent that is to set timings. If you only allow keystrokes to come in slowly, so I can't blast a bunch of stuff at you, it still takes a minute after so many keystrokes. So at any rate, it is something that we need to write down, it is something that we need to address and discuss when we go to the IrDA people. When you go to the ATM people and you say, "I want it so that my computer is linked to your ATM so that I can drive your ATM", you better, in the next sentence, say how that will raise questions in your mind, and these are the discussions. Otherwise, they don't want to say to the disabled community, "oh you can't do it because...", because they don't want to be negative, and instead they will sit there and listen to you but when you go away, they will just start throwing road blocks that you can't see.
?: What are the biggest intentions?
Gregg: Alternate keypad.
Neil: Alternate keypad. I think if we do that with caution about security issues based on giving identical access.
Gregg: Now there is one other thing that I found just recently about ATM's that I will mention just briefly here. Some of the keypads actually encode your pin number in the keypad and then it goes to the computer. The computer that is running this thing then sends it encoded to the bank. The reason they do that is so that a bank employee who is programming the computer in the kiosk can't put, I forgot what it is, but basically something that keeps track of the numbers it is transmitting. So the computer doesn't encode it, he keypad does. Now if you are doing an IR communication with the computer, there is no way that you can actually physically push the keys, therefore, how do you get your pin and code it so it is protected as it goes out the door? I don't know the answer to that one, but we also have touchscreen kiosks and they don't have encoded keypads so they must have already addressed the issue with those.
Gregg: The places that will probably make first progress are the ones that are totally computer controlled because there is no hardware. As long as we can stay at a software only solution, they can't claim costs. As soon as we get in to ask them to re-engineer their security hardware, we could be talking a million bucks. It is unbelievable what it cost to make up some of these new security projects.
Neil: Once the other people decide that this is the quickest and most convenient way of making transactions, then they will want it.
?: That is the only way it will happen.
?: Start with the population that is going to use it and demonstrate something that doesn't cost as much but in some way other people would use it.
Mark: Okay, good discussion, we have a couple more devices to add to #3. Under #4 we have a list of requirements we see that the Universal Disability IR Link will need to have. I am just going to walk down through them. This first requirement, the link must always be looking for a connection. This has to do with one's ability to locate or navigate to an information system and to interact with it. Second, there should be some type of security, and I think we just talked about that quite in depth. Third, the link must not interfere with other IR uses. That is one of the things we've got to be concerned about. There are a lot of other IR uses going on right now and we don't want to interfere with those. That means that we have to understand what a lot of the other uses are, other than our own, or the intended use of our own. The IR link must not be blocked by other IR. One special case we are already aware of is the link needs to support the talking sign technology or at a minimum, not conflict with it. There may also be a case where a talking sign device may run using this protocol as well. The last requirement on the list, is the user should always be in control of the link. In other words, the user makes a request, the system responds. The user is always the driver of this system. Do those make sense? Do people have other ideas they think should be of requirements to the system?
Gregg: What you were talking about earlier, Neil, was there another piece or was that just procedure?
Neil: I have been looking at the question of how a blind person finds a machine in an area where there are a lot of machines within close proximity. What I have been looking at is using the keyring transmissions because they can be very cheap, but they are limited in what you can do. What we were looking at, was the access device that essentially sends out a coded beam that says "there is an ATM machine here, so please turn on your IR beacon". The beacon we are using is a low frequency, 2.2 kbaud. That rate is used for TV controllers, and has long range, like 40 feet. So the machine that you have identified you want to talk to starts sending out an IR beacon that says "I am here and you can just swing your receiver across the air in front of you then when you are pointing at it, you will get some type of response". The RF does the location/identification dialogue between the two units on the low frequency. With the IR beacon, you move closer until you get in range, and then it says, "okay now we can get on with what we are doing". So, what it means is that you have this one-way radio link which is basically the translator between circuits, possibly, encoded, and can be made very cheap. It takes away a lot of the problems of having IR floating around the room. You have all of these machines there and they all respond, so you get into a horrible round robin of talking to each one to find out, and you also don't know where to point, to find what you are looking at. What we were looking at is a protocol that says, is there anything I can talk to that, and state what you are looking for, right down to is there an IBM PC or is there a Macintosh I can talk to or even Macintosh #15. The level you can put all encoded messages into this one little thing also comes into play when the link breaks. We are looking at a protocol when you are running at 150 kbaud, the link gets broken, and the system then reverts to the low speed IR to try to re-establish. If it still doesn't re-establish within a given time, it saves you from going through a whole logon again because since you told the system what to do. And you know that somebody is standing in front of you, basically. It seems to make a lot of sense to have the two technologies, because when we started looking for IR it actually got a response. Now I would have been traipsing between all the different machines which takes a lot of time.
Gregg: First of all, I like the idea, because the IR is quiet unless it is asked for. If you are looking for a bathroom, you are not sweeping around and just picking up something and listening. Why couldn't you ping in IR? If it can reach you, why couldn't you ping in, say, if it can reach you, you should be able to reach it. I am just trying to avoid having to put an RF transmission receiver.
Neil: Just standing there, I don't know that. What I was looking at was the power involved for a device that could IR flood the room. It may be more power than what we would get from some little handheld device.
Gregg: So you want to ping by radio and then look for IR replies.
Neil: Right.
?: I wonder about something in the requirements list, which talks about not interfering and not being blocked. Probably, you are going to have to have something that recognizes that blockage is going on in the IR level. It is not going to be possible to say we can come up with something that won't be blocked, because that only goes as far as what you find out is floating around at the time. So, you are probably going to have to recognize that there are going to be circumstances where the reason you run into problems is because there are all kinds of other activities, or IR activity.
Gregg: The nice thing about IR is that you can drive those little LEDs pretty easily and so even if you were just a little guy with a little battery if the ping doesn't last very long, even if it is a modulated carrier based IR ping, you can do a little wind up and blast a very bright ping and even your diodes, if you are only going to hit them for a short time, you can hit them a little harder.
?: 3-5 amps.
Gregg: Then you would have to be very short.
?: We do it all the time.
Gregg: No, I meant I don't know how long your ping is, but you don't have to melt before you get to the end of this ping. If you are doing flashing, however, you can hit it real hard. Since we are talking about if it is a carrier base, then they will be turned on for awhile. But for a battery, I wouldn't see it as being a problem because the ping is so short.
Neil: So we are looking at how the pieces will tradeoff and see if the same device that decodes the IR can decode the RF part.
Gregg: I would think the transmitter would be slightly more complicated because it has to be able to send different patterns, but the receiver only has to be able to receive what it is.
?: With the transmitter's ability to transmit the patterns into the rest of the intelligence of what you have.
Gregg: Right, that is what I am saying, but I am saying for the receiver end, it literally could be a switch. I am trying to think of a way for the ping idea, where the RF can work. I like the idea of it not interfering. It never occurred to me to mix technologies, because it probably would be more expensive. But maybe not.
The market is there. Somebody said that there were already 200,000 kiosks. I wouldn't have guessed that it was anywhere near that high. Almost any hotel you go into now has an information kiosk standing. This one has one, I don't think it works.
There is one thing in the scenario that I didn't quite follow. I followed it, but I didn't follow the logic. If the person is communicating and they loose contact, you said that the ATM could drop to the low frequency and re- establish contact, and tell them that it was having a problem. First of all, if it is not looking at the low frequency, I am not sure I would pick it up. Also, wouldn't both ends know that they lost communication at the same time?
Neil: Yes, but I don't know why. In this case, you don't know whether someone walked in front of her or if somehow you were just in range, and you moved out of range, but no matter how hard you try, you are not going to get it.
Gregg: You are dropping to the low just to see whether or not you have clear traffic.
Neil: Let's say that there is someone standing in front of us. To make it truly universal, you cannot have anything in the access device that knows what you are talking about, until you actually establish a link and have to pass back to the access device. Then match what my keyboard has written on it or what the menus are. So if you've taken time to establish that, you don't want to assume that the transmission is being finished just because someone stood in front of you. The ping used to say "I still want to talk to you, but somehow IR is involved." There could even be an audible sign that says, "get out of the way". The idea is to work out one of the practical time delays. You are on the IR link that we had going, and we are basically just storing everything at each end until someone walks away and everything races and catches up. One of the secure ways was logging off. We use the RF to say "I'm done." As the person turned away and is heading out the door, sign-off, ping. It may be something that we have worked on as being a time thing, where nobody responds after a certain amount of time, fine, probably gone home.
Gregg: It seems to me that you also ought to have a shut down. On a normal operation, you would say good-bye and close off. But if the person sitting there for a long time and doesn't hear anything, they would just assume that it was dead, and they would cancel the transaction.
Neil: There is dialogue that can't be required when you have a very complicated thing you are dealing with because you have never seen it before, so you don't have to re-set it up every time someone walks in front of you. The other thing we found that was very complicated was when you have two people wanting to access the same device to establish the protocol that they are sharing, because you have to assume that they can both see the host, but they can't necessarily see each other. It is easy if, for, example, there are two people in their wheelchairs who can see each other because you can essentially pass tokens back and forth. But when you've got two people who can't see each other, you can't have one crashing the other, so you have to get to the protocol with the host and it becomes a timing element.
Gregg: Isn't IrDA automatic already? Isn't it basically a buss structure; an IR bus, which means it automatically does all of the conflict resolution?
Neil: No, because you have to look at where they are at. What we are looking at is two people who can't see each other. It has to be dual process because the individual users still have to be in control of what they are doing, but the other end has to take it over and say "this is your time slot".
Gregg: I think at any bus structure there always has to be something that establishes itself as the master and everybody else requests time. I just don't know how IrDA does that.
Neil: It definitely wasn't in the IrDA information I have so far. The publications I received from IrDA hadn't reached that stage, when I was doing that part of thinking through.
Gregg: I have an announcement. The Trace Center is now a member of IrDA, and as the secretary of this group, we will be getting their regular announcements and have access to their listserves and mailings. We told them what we were doing, so I don't think there will be a problem with it.
?: What would that mean to me as a company or anybody else as a company, from the standpoint of doing something with IrDA?
Gregg: Well, if you wanted to do something with IrDA, then you should probably just join. What this does is when we are trying to work on this project, it means that the documents I received from IrDA would be public documents. They have another set, more comprehensive, that their members have access to, and they also have some listserves and discussions.
Mark: While we are on that topic, I just want to remind
people, that we have a listserve running at the Trace
Center, with a focus in the IR access area. If you are not
on, we encourage you to log on to that listserve if you have
internet capabilities. Send an e-mail to
Gregg: If your e-mail automatically puts your signature
block on the end of all your e-mails, then under the
subscribe message, on a new line, put two dashes and a
carriage return. That causes the system to automatically
ignore everything after that two dashes and space. That
will take care of it if you can't figure out how to turn the
signatures off.
Mark: Okay, there is quite a bit left on the handout that
we haven't discussed, but it basically goes through some
general ideas and discussion as to what we might consider to
be commands that we would need in our actual protocol for
the interaction. We have about 20-25 minutes left of this
meeting. I would like to turn this over to Gregg to give
you an overview of that, and then maybe we get into
discussions and commands.
Gregg: Basically what we are trying to do with the strawman
protocol, part V of the handout, is to take ideas that came
from all of the meetings and create a protocol, and say
"Let's try this, because it seems to meet what everybody is
saying and then if somebody can poke a hole in it we can go
from there." The introduction, the objectives, and uses, I
am going to skip through, except to say that this is
designed to be used by individuals both who have visual
impairments and physical impairments. It is designed to be
usable by people, for example, who come up to a kiosk, can't
see the kiosk, and would be using it to literally ask what
is on the screen, and then respond. It would also be used
by individuals with physical disabilities who would come up
to it, and can see the screen just fine, but are using a
sip-n-puff wheelchair. They don't need to know what is on
the screen, but they just need to be able to push the
buttons without touching it.
?: Then they do know what is on the screen.
Gregg: Yes, they can see the screen just fine. Their
problem is that they can't do anything about it. Part 1 of
the protocol is what the aid sends to the device. There are
basically three commands and they are: reset, list, and
activate. The purpose of the reset, and it may not be
necessary if we have a handshaking where you establish that
you are a new user, is if you come up to it and it is
sitting in a certain state and you want to go back to the
beginning.
List is particularly important for people who are blind who
would come up to it, and like anybody else, if you are on
some strange screen and you don't know where you are. List
is basically a request for a list of all information and
action items. So that would be fields on the screen, any
writing on the screen, any buttons, or anything that you can
do.
Activate is for when you want to activate something. You
can do it in two forms. You either give an item a reference
number, or you can use the verbal name of the item. The
verbal name is the name that it says. So if it is an arrow,
the verbal name would be right arrow or left arrow. That
name is given in the list of information. If it has a word
on it, it would be the word. So if you come up and want to
press the personal information button, you would type
"person". Actually, you can type only as much as you need
to. It would work because as soon as I got to "per" it
would probably send "per" and carriage return. If I said
"perf" and I hit a carriage return, it would beep because
that doesn't match anything. Otherwise it uses a "minimum-
to-distinguish" so that you don't have to type a long string
when there is only one button that starts with "per". That
is what it sends and that is the whole first half.
The second half has to do with the information that kiosk
sends back. Again, these are in keeping with our rules of
all responsive things. The only thing that is not a
responsive thing would be handshaking types of things,
things that Neil was just talking about. If it broke the
contact, both sides might start taking some initiative to
try and figure out what the problem was. Okay, in response
to reset, it sends back reset received instantly. So,
whenever you send a command, it comes back. Then, when it
is done resetting, it says done. That's done because if
resetting requires it to do something mechanical like close
a door, you don't want a person sending a command and then
nothing happening for some period of time. In many cases
you may never see the reset received because your machine
would say done. It wouldn't even get a chance to present
reset, received before the done command came in and overran
it.
In response to a list command, it sends back a tab delimited
table of all the items that are currently displayed and
accessible for reading or action. Each line in this table
represents a different item.
In response to activate, the device would send the name of
the item received. If I said "per" carriage return, it
would say personal information received and then it would
say done. It would do that with no return between them so
that if you were just displaying this information on your
display, it would say personal information done. Personal
information received, space, done. So the message would pop
up and you would know exactly what it did. If it had to go
to some page, it may say personal information and then you
would sit there and when it got to the new page, it would
say done. So you knew that you could now proceed to do
something else.
Now, the information sent back each information item, each
action item on the screen would have one line in the table.
So, on an ATM, there would be a line for the one, and the
two, and the three, and the four, and the five, and the
answer, and return, and each one would be a different line.
There would be a line for the instructions on the screen.
So, the person who is blind would be able to, if you are on
the screen, it says "hit one button to do x, y, z". That
would actually be an item in the table and that would be
called a field, and a person who is blind could select a
field and ask it to do that, etc. Each line would consist
of the following items. A reference number for the item,
#1, #2, #3, #4, #5. The #5 key might turn out to be
reference #14 if it is a keypad, they are just the numbers,
the reference numbers. The verbal name, so that if it is
being presented, for example, to somebody who is blind it
would say main menu. It doesn't send you a picture of an
arrow. It would say right arrow or left arrow, or something
meaningful. A value, if this was a checkbox, for example,
would tell you if this is checked or unchecked. So the
fifth item could be, include receipt, false, mark false, or
something. The fourth one would be type whatever it is. So
it would say main menu button versus main menu list or field
and you would know what it was that you had, whether you are
talking about a button or a field.
The last one is the position, which can be given in
coordinates. There is a number of different kinds of ways
to address that. The first line in the table would
represent a virtual item. It would be an item that is not
really on the screen and it would be called, description of,
and then it would say what the name of it was. It would be
like a main menu screen description. It ended up naming
whatever it is the context you are in. If you hit it, it
then starts giving you information. If you select this
invisible button, or if you select it the first time, it
will tell you where you are. If you hit it again, it will
say use this screen to select the major things or use this
screen to enter your key. If you hit it again, it would
tell you what the choices are available on the screen. If
you hit it again, it would actually describe what the screen
was laid out like in terms of buttons. If you hit it a
fifth time, it would actually describe the screen. Let's
say you are in recreation options of the DNR screen and it
would tell you it is the screen you use for selecting the
different types of information the DNR provides. The
description of the layout says there are six buttons, and
they are laid out like x, y, z. When you hit the fifth
time, it would say the screen presents a picture of a man
fishing on a lake or it is a collage of whatever, and it
tells you about all the graphics. In the upper left-hand
corner is the name of the company that produced this. It
tells you all sorts of information that you don't
necessarily need to operate, but it is contextual and it is
provided for people who can see. When you come to it, and
you say "Where am I?", it says "You are on a screen with a
man fishing." That is the fifth layer of information, and
most of the time you don't want it. We have also talked
about the bottom ones being optional. People really don't
want to take the time to describe the artistic nature of
their screens; they wouldn't need to, and that is not what
we consider the highest demand. Again, these are a few
layers of information that would be available. It seemed
that with that small amount of information, three commands,
three responses, and a table, you could do everything you
needed it to do, including almost creating a fifth position,
like four coordinates for each item rather than just a
verbal description. I don't know what we want to do. You
could actually have the screen semi-reproduced. I don't
know how far we want to go in that direction.
Neil: The off shoots of doing this is that it makes it
possible for people to transact over the phone. I think
this again is looking at how it applies to people who are
not disabled, and so it means that the same protocol could
be used, but there is a modem and something else that would
link. There are a lot of things interacting over the
internet, or over the phone with remote devices, which
brings up exactly the same set of problems. For instance,
with the buttons, work on how to encode what a keyboard
looks like with the least hassle, knowing that this model of
Macintosh looks like PC models. What we have been working
on was defining the different types of keys on a large
keyboard. It is a lot of repetitive information if you put
in all four coordinates. You send out that there are three
types of keys on this keyboard, and these are their
dimensions. Then we give the top left coordinate written in
order of scanning from top to bottom and left to right.
Take a physical keyboard, which means that everyone will get
the same answer if they scan a keyboard. The first corner
you hit becomes a sequence number which we talked about,
because there are a lot of different keys, and they
take into account microwave ovens with funny layouts which
is something you heard that you can scan now. We are
visualizing to be able to take a blueprint of the thing, put
it on the scanner, and the computer. We are able to
generate what the code would be, and if you do it, you get
the same answer as I do. And so that was one of the things
we get some consistency in, in terms of knowing what the
number of what key should be called.
Gregg: The interesting parts, when we get off of keyboards,
is where I am trying to correct in my head is we get
pictures of screens with people standing around talking, and
the balloons, but you could still, as you said, say there
are so many hot spots and they are about this size in the
upper left-hand corner. Do you make them into rectangles?
If it turns out to be a cluster of circles around a circle,
then we will have more difficulty. The question sometimes
is, do you need to do it? That is an artistic way of
representing 12 choices. The table, of course, lets you do
that and you can ignore the positions and just deal with it
as a list of choices, or as Neil said, you can try to
reconstruct it. The other thing interesting about this is
that you could actually have a screen where you have a set
of choices, and then you have three choices which are little
cherubs moving around on the screen carrying products, so
they don't have a position. The position would say, cherubs
flying around screen but it really doesn't matter because
you have ten choices, and you are just going to pick one of
them. The fact that they are moving around, or walking in a
circle, or a carousel, as another example. A carousel
rotates, and you pick things off a carousel, but at any
point and time you have so many choices that are in that
context, and this would allow you to access them. I worry
about that a lot because I don't want us to design something
that is going to work for technologies today, because no one
is sitting still. Somebody was talking about the fact that
people need a different way of doing things, and so all of
the companies want to differentiate their products. Because
everybody is doing it, however, is not the way they want to,
because they want to be doing it differently. Were there
other things, Neil, that you didn't see in here. You are
making a case of the position.
Neil: What we worked on, was that not to embed ASCII codes
or anything like that in the access device. What gets
transferred to the access device is what is written on the
button so basically it is the legend and a generated number.
Gregg: Yes, right.
Neil: So if I am using speech recognition, it doesn't
matter if it is in the top left-hand corner, or if it is a
cherub flying around on an elevator.
Gregg: This table that we have talked about meets your
criteria.
Neil: It does that. All of the different disability
devices we can think of will have enough information to
generate what is needed. Also, the things that we will be
controlling at times don't exist yet. How do we make sure
that whatever we do to the machines will make the very first
one still work with something that turns up in five years
time. Part of the protocol needs to be, "Hi, what are you,
what do you need from me?" Some arbitration goes in the
initial conversation they have that says "This is the subset
that we can both manage so you download your list and at
that point you can then talk about it, because there are
only certain physical things that can happen even if they
get drenched out in the most weird and wonderful graphics
themselves." Still come down to a physical list, you have
to have a way of sharing that physical list back and forth.
This is a good subset of what we are looking at in terms of
full fledged keyboards being able to just use three or four
buttons on them.
Gregg: Question. You said this is a good subset of what
you are trying to do. What elements are missing that you
want to consider?
Neil: What I was meaning was that when you start a
keyboard, you have a lot more of them. You just have a
longer list. It is virtually identical thinking, it's a
number, it's a legend. It's just a matter of how do you
allocate a number in a machine you've never seen before.
The other thing we looked at was if there is something you
work with all the time, and it has a complicated keyboard,
you don't want to have to go through arbitration and swap
the files every time you start up. So part of the protocol
should be, "Do I know you?" Something that says "Hey, we
are all friends. I have everything I need to know to work
with you, so start working."
?: Remember the last time?
Neil: Yeah, but basically something that says "I already
know where you are, let's get on with it."
Gregg: Would it really matter? The data rates we are
talking about, even if you had 101 keys, you could transfer
the whole table in 1/100ths of a second.
Neil: If you had legends, descriptions, and position codes.
It is more than when you break the link. Somehow you get
just at the recovery time, but then have to re-establish it,
and you go through 30 seconds of arbitrating, setting up,
and redrawing.
Gregg: Because you are thinking of the redrawing, actually
creating a keyboard?
Neil: One of the problems in a lot of the artificial
scanning software was that it described things of a physical
machine. It says press the gray button beside the minus
key, and there is no gray button next to the minus key. We
need to make it so the person can follow the built-in
instructions. It is important that you can recreate the
actual key with minimum overhead, and it will minimize the
amount of time we should be doing those sorts of tasks.
Gregg: It sounds like an advertisement for Sentient Systems
or one of the systems that has a graphic dynamic display.
Neil: It is frustrating seeing someone looking for
something that is not on a key.?
?: Particularly since instructions are so geared toward a
visual element.
Neil: That is were it came up. People were trying to read
the handbook.
Gregg: It sounds like we should then have a 5 and a 6
position in the table, for example. This gives you a verbal
statement of where it is. I wrote a graphic reconstruction
information, and maybe it is something that should be sent
as a block of data rather then a piece at a time.
Neil: It would be a block. The three buttons usually are
dimensions.
Gregg: So I think the graphic reconstruction information
which would be sent wouldn't be a number 6 here, it would
actually be a separate line in the table because it is
something you would ask for once. You wouldn't want the
graphic reconstruction given to you one piece at a time.
You would want it done one screen at a time. If you are
going through a kiosk, every screen is going to be
different, so you need to be making sure that it's a line of
the context. You know I can actually see that it might be
PDF or something were you literally ask for a description of
the screen, and you would literally be able to recreate an
exact image of the screen.
?: Certainly not unrealistic.
Neil: The information would be in such a way that you can
do just a straight single line, a simple one as well with
enough information, if you can recover, real dumb, simple
little devices.
Gregg: That is a whole area of study to think about. Was
there anything else? I think one of the things that was
also mentioned is that we really should do the PPP
handshake. It should be in our strawman thing. We ought to
describe what it is. And also the kinds of things Neil was
talking about, the linking. If we are proposing to do
something, we ought to write one up and stick it on the
protocol and then somebody else can say that they violently
oppose using RF, or that they think hat it is a great idea.
Neil: I was waiting to get around to doing it. I will
follow up with National and Maximum, and see what it would
cost if they were to have a chip.
Gregg: First of all, are there any questions about the
protocol or the strawman? The protocol makes sense.
Secondly, do you see any holes, or errors? The third
question is, do you see anything that doesn't work? One of
them was what Neil talked about, which I added on, is the
reconstruction data. We really didn't have enough data here
to reconstruct it. I guess the way to think of this is to
think of it from the consumer standpoint, and just think of
the different kinds of consumers. Think of them coming up
to a kiosk and coming up to an ATM, coming up to a point of
sale and trying to do things. Somebody on sip-n-puff, or
somebody on a portable Braille display so they are really
reading Braille. It's just going to be what are my choices
so I can choose my response. Try to see if there is
anything you would want to do, that you couldn't do with
this set.
?: Individual users fully agree to??
?: Were you sitting up, or standing?
?: Because they couldn't see the display.?: Or if they are
using a head pointer.
?: They are using a head pointer on their own display and
selecting things by looking at them.
Gregg: The other interesting one was the modem over a phone
line. I hadn't thought of that one.
Neil: If you make that something that is easy for them to
do, then it becomes useful to more people. I think that is
the key nowadays, so other people will use it.
Gregg: They will probably want to use it as a client-size
image map, so it will work with the web clients. I am
beginning to think whether or not we can get rid of reset
because any good design system always lets you get back, and
if it doesn't, there is probably a good reason it doesn't.
If we do the handshake, I was worried about somebody coming
on board. If there is a handshake, any kind of a protocol
will get you going that ought to reset. A person should be
able to know if it's talking to a new person, or if it is
re-establishing a broken contact. Maybe in the handshake.
I am going to circle "reset" with a question mark, and just
say "handle by handshaking". I hate to drop something quite
that fundamental, but I love having a protocol that only has
four commands. There are two commands and two responses,
because it will be a lot easier. It is a lot easier to get
somebody to talk about carrying it. Especially IrDA, if we
want to get it carried in the protocol. Generating the list
may be harder to get the people to build in, but the first
step is that we need to get it into the protocol.
Neil: In a lot of cases, if you really have a thought
through protocol, they can just pick the code up and drop it
in. They don't have to develop it.
Gregg: That is how we were able to get things into Windows
95. Not only just the code, but they can see it in
operation and can examine what they should be afraid of.
When you are talking generalities, they are always afraid of
everything. When you are talking specifics, then they can
really look at it and see if it looks like a can of snakes
or a can of worms.
?: The thing that keeps going through my mind is we are
talking about products that are out in use by the general
public and somebody took the job of writing the software
that is in there, and now we are asking what we need to do.
I question whether anyone buys it.
Gregg: The place it will start is public information
system, transaction systems, and fare systems, because there
is a law that says you have to make these things accessible
if it is reasonable. If you make ATM's and you want the
market, like everybody else, and you can make it accessible,
then it is now reasonable because you are doing it. If it
is reasonable, everybody else has to do it and only you have
yours done and they have to go back to the drawing board.
There is a real advantage and, therefore, an incentive to go
out and do it first. This is what is a major driving force.
If it is not reasonable, you can't do it. This is how
Microsoft, now that they built in their disability access
stuff, it is very hard for someone else to say it is not
reasonable because everybody knows it is. If it is all in
there, it obviously can't be something that is unreasonable
to do.
?: Similar to what happened to the section 508. GSA did
not enforce it until quite recently, because they could not
defend the fact that there was a reasonable solution
available. As soon as a reasonable solution had become
available, they did enforce it. Until this thing has been
proven to exist, and it is economically feasible, the
standards are not clear.
END of meeting discussion on tape...
------------------------------------------
APPENDIX:
A "Straw Man" PROTOCOL (what travels through the air) FOR THE UNIVERSAL DISABILITY IR LINK PROJECT
Introduction:
Based on input to date and our past meetings, the
following "straw man" protocol has been developed to give us
a reference point, and a point to begin discussions. This
does not include a bit of hand-shaking that would have to
take place up front to establish a secure connection, etc.
Objectives:
Uses:
NOTE: The IR link is NOT intended to replace direct access
to Information Appliances (i.e. the ability of people who
are blind or have other disabilities to use the appliances
directly). This is still the goal. However, we as a field
do not yet know how to practically make appliances that can
be accessed directly (e.g. without assistive devices) by
everyone, (e.g. people who are deaf blind or who use sip and
puff or eye gaze to control things). The IR link allows a
mechanism for these people (and others who prefer) to access
information systems using their personal assistive devices.
It may also an allow inexpensive way to add access to a
wider array of products.
THERE ARE 3 COMMANDS THAT CAN BE SENT BY AN ASSISTIVE DEVICE ("AID")
NOTE: when the user sends the "list" command, the device may optionally display the names or reference numbers next to the items on the screen to facilitate access by users who can see the screen but who must use an alternate device connected via the IR-l
ink to "push" the buttons etc.
ALL INFORMATION SENT BY THE "INFORMATION DEVICE" IS IN RESPONSE TO COMMANDS FROM THE USER (AID)
In response to RESET
In response to LIST
In response to ACTIVATE
Details on the Description table sent in response to LIST command
2nd activation, The function of this screen (context)
3rd activation, The choices available here
4th activation, Description of the layout of the items on screen
5th activation, Graphic description of the screen or context
ATTENDEES:
Mark Novak
Kim Henry
Kathleen Miller
Neil Scott
Deb Finn
Larry Shirer
David Bayer
Gregg Vanderheiden
Maureen Kaine-Krolak
Wendy Chisholm
Neal Ewers
PART I: Protocol for communication from the "aid" to the "information device"
SHORT-NAME
COMMAND
DESCRIPTION OF COMMAND
1.
RESET
#R <ret>
reset system to start (local home)
2.
LIST
#L <ret>
send a list of information and action items
3.
ACTIVATE
#item reference number <ret>
or "verbal name of item" <ret>activate this item PART II: Protocol for communication from the "information device" to the "aid"
END of strawman protocol...
1st activation, Where the user is
Trace Research & Development Center
S-151 Waisman Center
1500 Highland Ave.
Madison, WI 53705
(608)263-3812
Sentient Systems Technology, Inc.
2100 Wharton Street
Pittsburgh, PA 15203
(412)381-4883
Consultants for Communication Tech.
508 Belleune Terrace
Pittsburgh, PA 15202
(412)761-6062
Archmedes Project
Stanford University
Cordeura Hall Rm. 118
Stanford, CA 94305
Industry Canada
Communications Research Centre
P.O. Box 11490 Stn. H
3701 Carling Ave.
Ottowa, Ontario Canada K2H 8S2
Finn.deb@ic.gc.ca
APT. Technology
8765 TWP Rd. Suite 3
Shreve, OH 44676
Du-It Control System Group, Inc.
8755 TR 513
Shreve, OH 44676
(216)567-2706
Trace Research & Development Center
S-151 Waisman Center
1500 Highland Ave.
Madison, WI 53705
(608)263-5788
gcvander@facstaff.wisc.edu
Trace Research & Development Center
S-151 Waisman Center
1500 Highland Ave.Madison, WI 53705
(608)263-0804
kaine@trace.wisc.edu
Trace Research & Development Center
S-151 Waisman Center
1500 Highland Ave.
Madison, WI 537059
(608)265-2808
chisholm@trace.wisc.edu
Trace Research & Development Center
S-151 Waisman Center
1500 Highland Ave.
Madison, WI 53705
(608)263-5485
dnewers@facstaff.wisc.edu