RE: The top three big problems

  • From: "Chris Hofstader" <chris.hofstader@xxxxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Mon, 15 Oct 2007 15:48:14 -0400

MSAA is a problematic standard as virtually every implementation of it in a
mainstream application requires the screen reader either be configured, in
good MSAA implementations, or actually changed internally in more difficult
cases.  I think some of the newer API like iAccessible2 deals with some of
the ambiguity and lack of context in MSAA.  If my sources are providing me
with good information these days, IBM is apparently paying FS to support
iAccessible2 in JAWS but I don't know anything about Window-Eyes, System
Access or HAL/Super Nova.

The problems with testing against screen readers compound when something
that doesn't work out-of-the-box can work with a simple script or
configuration change to JAWS or Window-Eyes which are not readily available
with System Access or HAL.  A pure API solution, especially in a Windows
application, doesn't always work as one would expect and relying on the OSM
can get tricky as they are the result of a pretty inexact science.

I think the best thing to do is to take suggestions from as many blinks as
possible and then get a beta team of programmers who use screen readers to
really bang on the software and, where it seems prudent, write some scripts
or .set files to make it work better while also reporting to the author how
they can make changes to make the experience better.  Often, a sighted
person trying to use a screen reader will create strings with vastly too
many syllables and make other "beginner" mistakes as they have little basis
for any assumptions they need to make.

cdh



-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of John Greer
Sent: Monday, October 15, 2007 2:10 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: The top three big problems

I still say the programmer that is doing the software, sighted or not should

download and use his or her software with an actual screen reader.  The only

true way to understand how to program for accessibility is to use a screen 
reader with the product.  A mound of definable hotkeys are all fine and good

but if the control the hotkey points to doesn't give usable vocal feedback 
then the hotkey is useless.  If the plan is to put some sort of intellisense

into the product then I feel the programmer should, at design time, use the 
product with Jaws, Window Eyes etc. and see how closely the vocal feedback 
is to what is visually on the screen.  He or she should tab to each of the 
controls to see if the control can be accessed using a screen reader, and 
make sure the control is labeled in a way the screen reader can actually 
read what it is.  I can guarantee that there are little quirks with screen 
readers that a manual on MSAA does not cover.  So again, I suggest that any 
sighted programmer looking to make software for the blind, download and use 
a screen reader with their software.  If the sighted programmers are saying 
to themselves, "But I don't know how to use a screen reader".  I say to them

neither do 80 percent of your screen reader users, so you have to make 
access to the controls as simple as you can for that 80 percent.  Also many 
sighted programmers may say but the voice just annoys me, and I say welcome 
to the club but it is how we do it.
----- Original Message ----- 
From: "Octavian Rasnita" <orasnita@xxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx>
Sent: Monday, October 15, 2007 11:40 AM
Subject: Re: The top three big problems


> And I can also say that I don't like some of the key combinations in 
> VS.net at all.
> I never liked that combined combinations like alt+Q,S, or Control+Q,S... I

> don't remember.
>
> It would have been more simple to be control+Shift+S, or alt+Shift+S, or a

> combination which is more clear.
>
> For example what happends if I press Control+Q but then I want to not 
> press it anymore? I don't know what will happen if I will press another 
> key because it might do some bad things. I also don't know if that alt+Q 
> is remembered or it is forgot if pressing another key than S or other 
> valid key.
>
> I don't know why VS.net uses those strange hotkeys. If there are too many 
> hotkeys and that's why, than this is bad. There shouldn't be too many 
> hotkeys defined by default, because they might cause conflicts with the 
> screen reader's hotkeys, or anyway, the user won't remember them all, so 
> they will have no value.
>
> Octavian
>
> ----- Original Message ----- 
> From: "Jamal Mazrui" <empower@xxxxxxxxx>
> To: <programmingblind@xxxxxxxxxxxxx>
> Sent: Monday, October 15, 2007 5:57 PM
> Subject: Re: The top three big problems
>
>
>>I suppose that copying the keyboard model of either Visual Studio or
>> Eclipse makes sense because of the popularity of those environments.  In
>> the case of VS at least, however, I wish to express the opinion that the
>> keyboard assignments are not particularly intuitive or easy to remember.
>> The base letter of a key combination is often not the initial letter of
>> the associated command.  Many commands require chorded sequences of hot
>> keys, sometimes where the second one also requires the Control modifier
>> and sometimes where it does not.
>>
>> Jamal
>>
>> __________
>> View the list's information and change your settings at
>> //www.freelists.org/list/programmingblind
>>
>
> __________
> View the list's information and change your settings at 
> //www.freelists.org/list/programmingblind
>
> 

__________
View the list's information and change your settings at 
//www.freelists.org/list/programmingblind



__________ NOD32 2591 (20071014) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com


__________
View the list's information and change your settings at 
//www.freelists.org/list/programmingblind

Other related posts: