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

Hi Pete,
I'm not a programmer or even a particularly technical person, so when people 
say scripting, I generally get discouraged. I think I commented earlier that 
one of the things I dislike about scripts is that if something 
changes in a new version of an app, scripts often break, and end users are out 
of luck until somebody can come along and fix the script. Would that be 
different with the system you are proposing? The other 
thing, of course, is that the huge majority of end users will never be able to 
write scripts, so if they are dependent on them to make badly behaved apps 
behave, and there is no script for the app they need, they 
are stuck. I know that there are times when there is no way around that problem 
with the existing screen readers, and it may be that scripting will be 
necessary for the new one too. I certainly like your idea of not 
having to know how the form is structured in order to deal efficiently with it. 
There are people out there who say that its a disadvantage, that we should deal 
in exactly the same terms as our sighted colleagues, so 
that interaction with them is smoother. I see the point. But I think that 
getting too hung up on the visual aspects of something, can be a serious 
detrament to making something that is intuitively usable by blind 
people, especially those who have never had vision.
Mary

On Thu, 05 May 2005 22:45:26 -0400, Peter Parente wrote:

>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: