[ossrp-control] Re: What Is A Screen Reader?

Hi Pete,

Again I agree, but have one soap box point. Again, it is the amount of resources needed for scripting, or other forms of interface customisation. It's going to take time for someone to learn the interface, decide on and design an alternative interface, and then code it. Multiply this by the vast number of applications that are out there, and you have a huge demand on resources, a demand that likely cannot be filled.

When I co-wrote the chapter for the Encyclopedia of HCI that covered similar ground, my co-author and myself proposed that this could be achieved through a standard three tier n-tier architecture, with either a plug 'n play interface layer through COM or a similar technology, or through late binding and polymorphism of the presentation layer. Our rationale behind this was that the developer of the application knew which semantics were necessary to convey through the interface, and thus didn't have to learn them. Additionally, as they were interacting with the logic components of the n-tier architecture, there was no need for any semantic translation between two different interfaces, something that could be a potential source of semantic translation errors.

So, I agree that this is a good approach, but the resources required to make a substantial proportion of the applications in use accessible is a little cause for concern.

Will
----- Original Message ----- From: "Peter Parente" <parente@xxxxxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Friday, May 06, 2005 3:45 AM
Subject: [ossrp-control] Re: What Is A Screen Reader?


Hi Mary,

I think your comment about about needing the cooperation of software developers to change the way their visual interfaces are structured touches on some of the potential power of user interface automation technologies. Say, for instance, that a wizard turns out to be the most efficient way for a screen reader user to accomplish some task, but, unfortunately, the application GUI isn't structured like a wizard. Instead, it has a bunch of panes in the main program window that have to be filled in a certain order. Given that the screen reader can inspect and control all of these panes, what's to stop it from presenting them as a wizard to the user? Does the user really need to know that the steps he or she needs to take to complete their task is structured as a set of panes in some containing window? Probably not. So why not let the screen reader collect the necessary information from the user by acting as a wizard and let it do the menial work of entering it properly into the GUI?

Now, this doesn't mean that there isn't some human work involved here. Someone still needs to tell the screen reader (e.g. through a script) that the window panes should be re-structured into an audio wizard. But at least this approach affords the possibility of improving the usability of an application without being totally dependent on the original software developer. Some third-party could write the script.

At present, though, the scripting languages available for screen readers and the interface automation technologies do not make this type of abstraction easy, but it is possible. Improving the ease with which an application can be scripted to provide alternative representations of program tasks in audio is one of my goals in building Clique.

Regards,
Pete
To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes




To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes

Other related posts: