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

Hi Will,
I think that David Landt's point, in another  message on this thread, is worth 
investigating. I too used the screen reader he talked about, with the means 
whereby a user could "teach" the screen reader what he or 
she wanted on a particular screen or application. This is, in my view, more 
efficient than asking blind people to learn an entirely foreign modality in 
order to interact efficiently with an application, and doesn't have 
the problem of resource scarcity  that you referenced with regard to scripting. 
  There are things about visual interaction that can't be duplicated well with 
audio. I saw that Mercator project you referenced, as did 
blind colleagues where I use to work. We did not like it, although that was 
probably in part because of how different it was from anything any of us was 
use to. But that is the point. There is a major learning curve 
for many blind people with respect to the semantics of spacial relationships 
which sighted folks take for granted. So when you speak of making more things 
accessible by taking advantage of spacial relationship 
semantics, I question the accuracy of that concept. Its not accessible if 
understanding the semantics is foreign to me.
Mary Otten
senior tester
Tecaccess

On Fri, 6 May 2005 20:18:40 +0100, Will Pearson wrote:

>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




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: