[nvda] Re: Audacity problem

Well my point was, for Microsoft Windows the standard accessibility model is MSAA. The reason why Narrator and others also can't read the control is because there is no MSAA information associated with that control. Jaws and Window Eyes however have another method they can use to extract information. In most cases Jaws can extract information through its video intercept drivers. NVDA however does not have video hooks. Nor does Narrator and Thunder. The main limitation to the Microsoft Accessibility model is that most programmer's dont use MSAA to make it accessible. In the case of Audasity though, they are last time I checked at 1.3 beta with the goal to make Audasity more accessible to screen readers. I am almost certain they are using some aspects of MSAA to achieve this. I am also certain that things like the radio buttons not being associated with their text could be an oversight on their part because there are many applications that when you move the screen reader to a radio button it also reads the text associated with it. Now as I said Jaws and Window Eyes do have a bit of an advantage because they can use video hooks in order to extract certain information, Skype 2.0 is a case in point. With the skype team, the screen reader users, scripters, and programmers let Skype know about the issues that most screen readers had with their menus. Now Skype did fight the change they had to make but when they realized it would be to their advantage to correct the problem they released Skype 3.0 with an option to turn on accessible menus. But yes in many cases you do have those programmer's that just refuse to help make their software accessible, but I don't believe Audasity is doing that, otherwise they wouldn't have made one of their reasons for version 1.3 to make it more accessible to screen readers. ----- Original Message ----- From: "Gene" <gsasner@xxxxxxxxx> 
To: <nvda@xxxxxxxxxxxxx>
Sent: Wednesday, September 26, 2007 3:18 AM
Subject: [nvda] Re: Audacity problem



John

You wrote in part:

As for the original subject of the thread.  If

the programmer's of Audasity will put in 2 or 3 lines of code as an
identifier of those radio buttons, it would save the programmers of NVDA, Jaws, Window Eyes etc. hours of work trying to extend the capabilities of 
the screen reader to accomodate a single application.
I didn't raise the Audacity question as just dealing with a problem with one single application. I raised it because the same problem that causes NVDA not to see the associated text with the radio buttons may occur in many applications perhaps a large number. I have no idea how many applications may have this problem. I also don't know if the problem is limited to radio buttons or if it can happen in other structures as well. My point is that if the NVDA developers identify the problem, they can then determine how likely it is to affect just a small number of applications or a significant number. I don't expect NVDA to solve this problem immediately. I don't know how serious the problem is so I don't know if, or when it will ever be solved. However, NVDA, as I understand it, has the goal of providing good access to a wide variety of applications. Yes, if the Audacity developers add code, that's fine but that doesn't mean the problem will be solved. It will just be solved for one application. JAWS and Window-eyes both see the text associated with the radio buttons. System Access, NVDA, Thunder and Narrator don't see the text. My question is why NVDA doesn't see it and what the implications are for NVDA. Yes, developers should make programs accessible but in the real world, screen-readers need to do what is reasonable to function in less than ideal conditions where material is actually accessible but may not be available in the most common or simple manner. Perhaps this is a limitation caused by the lack of video hooks, if that is the correct term and NVDA can't correct it until such time as hooks are created. However, since I don't have the technical knowledge to know or research the problem, I report it in the interest of further development. If this problem occurs in thirty or forty percent of applications a blind person may want to use and JAWS and Window-eyes don't have this problem, it makes no sense to believe that these thirty or forty percent of applications are going to be modified by their designers to solve a problem where the most widely used screen-readers don't have difficulty. Even where a problem affects all screen-readers, many designers are simply not going to do anything about it. 

Gene
To post messages to the list send email to
nvda@xxxxxxxxxxxxx
To modify your NVDA Email settings go to:
http://www.freelists.org/list/nvda
Thank you for your continued support of Nonvisual Desktop Access, an open source free screen reader for Microsoft Windows: 
http://www.nvda-project.org/
To get the latest NVDA snapshot:
http://www.nvda-project.org/snapshots/
Report bugs or make feature requests at:
http://trac.nvda-project.org/
Message Archive:
http://www.freelists.org/archives/nvda



To post messages to the list send email to
nvda@xxxxxxxxxxxxx
To modify your NVDA Email settings go to:
http://www.freelists.org/list/nvda
Thank you for your continued support of Nonvisual Desktop Access, an open 
source free screen reader for Microsoft Windows:
http://www.nvda-project.org/
To get the latest NVDA snapshot:
http://www.nvda-project.org/snapshots/
Report bugs or make feature requests at:
http://trac.nvda-project.org/
Message Archive:
http://www.freelists.org/archives/nvda

Other related posts: