[nvda] Re: Some random thoughts

This same sort of issue came up between me and a friend of mine concerning Jaws and what it can and cant read. Or should and shouldn't for that matter. The problem is simply that a screen reader can only convey a limited amount of information to the user. Blind people seem to have this notion that if their screen reader does not speak every action taking place on the screen they are missing out on something. Sometimes this is true and sometimes it isn't. My friend was asking why the Microsoft pinball game Space Cadet couldn't be made accessible to screen readers. I told them because the screen reader simply cannot track that much visual information and convey it to the user in a reasonable amount of time for it to still be relevant. Further example is, if a bumper turns red for 1 second and if you hit the bumper within that second you get 1,000,000 points. In the case of getting a screen reader to convey that information, in the second that it takes the screen reader to recognize the event has taken place and speak it the event has already passed. My point is that no screen reader is ever going to be able to convey every bit of visual information that is going on at all times in Windows, so what the screen reader programmers have to do is convey the most relevant information to the user for the job they are trying to perform. Just because a screen reader does not read this or that information does not mean that no one will want to use it. Just because a screen reader does not work in the way that you hope also does not mean that people won't use it. I have in the past five years used Window Eyes, Narrator, Jaws, System Access and NVDA. Each and every one of them convey information in different ways. To the people that have consistantly said "No one will be able to use NVDA, no one will want to use NVDA because it doesn't do this or that keep in mind this. A screen reader will never be able to interpret the screen as efficiently as the human eye. It can never be the equivalent of a human eye. In order for any screen reader to tell that a program is doing this or that, the program has to convey certain information to the operating system and the screen reader then has to filter through what is relevant and what is not and speak it. However if a program simply does not convey meaningful information to the operating system or in some cases none at all then, the screen readers cannot see them. The human eye may be able to see that something is there but that does not always mean that it is giving the information needed for a screen reader to see it. That is why they call a screen reader an adaptive aid and not a human eye replacement. I find it a bit unfair when the programmers of NVDA are scolded for being a bit reluctant to add a new feature. it seems every time there is someone out there that throws the "Well no one will want to use NVDA if..." argument out there. Have you ever heard the saying you can please someone some of the time but not everyone all of the time? That means that NVDA is not going to act exactly how you hope it will all of the time but it does not mean that it is not still useful to others. Ok off of soap box now. ----- Original Message ----- From: "James Teh" <jamie@xxxxxxxxxxx> 
To: <nvda@xxxxxxxxxxxxx>
Sent: Monday, February 25, 2008 6:09 PM
Subject: [nvda] Re: Some random thoughts



Hi all,
I am often given the impression that users believe we're being idealistic just to be difficult. This is not our intent, as should be obvious given the cause. We are trying to avoid simply repeating everything that other screen readers have done, potentially making the same mistakes as well. We're also trying to maintain a certain amount of consistency, which is very much lacking in other products. We'd rather try to apply a general rule wherever possible, rather than applying a badly thought out rule which has to be overridden in 90% of cases for specific applications. This is poor design and is unfortunately becoming more common. Having said this, we are aware that a general rule is not always possible and that there are always exceptions, but these exceptions should be just that: exceptions, not rules.
On another note, people suggest that they want configurable verbosity so that they can choose what should be spoken in these difficult, controvertial cases. Such configurability is not as simple as it seems on the surface and can lead to greater complexity, not just in code and efficiency, but in useability as well. Providing "beginner", "intermediate" and "advanced" verbosity is not enough, because, for example, some advanced users might still want to hear about icons, while some may not. Conversely, providing an option for every single one of these cases (e.g. whether or not to speak "pane", whether to speak "icon", etc.) makes for an excessive number of configuration options which, aside from being confusing for the user, eventually makes for a slow, bloated and inefficient code base.
Regarding speaking of window roles: The problem when considering these issues is that sometimes, semantic information is lost by not speaking these roles. Consider the following: * If we eliminate the speaking of too many roles, we will have seemingly arbitrary chunks of text spoken which don't appear to make any sense. For example, if we silence the "panel" role in the Java Control Panel, which is used to indicate grouping of controls, you will hear something like this on the general tab: 
"About <pause> About... button"
Some might wonder why "About" is spoken twice. If "About panel" is spoken for the first, it makes it obvious that the button is inside a panel also called "About". Those of us who are familiar with this know that a pause probably means a different control, but some might not. * It seems that most don't want "pane" to be spoken for a foreground window, yet they are happy to have "dialog" spoken when entering a dialog window. Why should these be any different? One might argue that the former is a normal case and so needn't be spoken, but it could also be argued that this is pointlessly inconsistent. * The "icon" role is particularly controvertial. "Icon" actually does convey information that might be useful in some cases, although it isn't actually useful in terms of the behaviour of the control. "Icon" indicates that the item that is displayed is a graphical representation, not a piece of text. This isn't much use to a blind person in most cases, but could be useful in terms of one's understanding of the operating system and for communication with sighted peers. 

My rant aside... :)
Mick and I have agreed to silence "pane" for application windows. In addition, "grouping" and perhaps "panel" will be silenced. We need constructive, useful feedback on changes like these.' 

Jamie

--
James Teh
Email: jamie@xxxxxxxxxxx
WWW: http://www.jantrid.net/
MSN Messenger: jamie@xxxxxxxxxxx
Jabber: jteh@xxxxxxxxxx
Yahoo: jcs_teh
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: