[nvda] Re: Some random thoughts

I'll write more later on other points but I'll address a few here:

I am making no assumptions about idealism.  However, there is often a good
reason why things you object to find there way into or out of
screen-readers.  Obviously, I don't want the mistakes of other
screen-readers to be duplicated but mistakes are at times in the eye of the
beholder.  My main objection is to a craving for rules that dwarfs past
experience of lots of blind users and common sense.  The discussion of
dialog versus pane announcement is such a case.  You need to know what kind
of field you are in or what kind of structure you are in when that affects
what you do.  Obviously, if you enter a dialog, you need to hear this
because you function completely differently in a dialog than in the edit
field of the main window of a word processor.  Pane is usually unnecessary
and redundant information.  You are in a pane, by definition, every time you
are in a window.  Announcing pane is like saying wheat flour bread.  Most
bread is made from wheat flour.  Therefore, no one makes a distinction
unless something like potato bread is served.  In the same way, pane is
completely redundant because by definition, you always are in a pane of some
sort.  Actually, maybe that's not literally always true.  Maybe you aren't
in a pane when you are on the start button.  But you almost always are.  If
a window is divided into two panes, is hearing pane useful information?
That's a question worth considering.  It might make some sense to have pane
announced when in a help system to alert the user that f6 will probably move
him/her from pane to pane in the same window.  but when you open Notepad,
Wordpad, etc. by definition you are in one pane and only one pane.

I don't want to make more of this than it is.  It isn't going to matter much
whether a user hears the word pane when a program is opened or moved to.  At
the same time, I'm trying to make a broader point.  Adhering to a rule or
trying to adhere to one because one wants consistency is of no value if
consistency is placed above what makes sense.

I'll give another example in a different context.  When using search, NVDA
announces selection removed or something similar when you move away from the
selected text.  This is another example of providing bothersome pretty much
meaningless information to the user.  I definitely don't want to search a
document, at times conducting many repeated searches of the document to find
the correct item I am looking for and have to hear selection removed every
time I down arrow to see what is below the line of text I am on.  This
appears to me to be another example where a wish for consistency takes
precedence over what makes sense.

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