[ddots-l] Re: Are we speculating or do we know what is really happening?

Amen, Brother.  You've really laid it out well.
Kevin
On Jul 8, 2011, at 3:14 PM, Bryan Smart wrote:

> Every situation is different.
> 
> With Native Instruments, it's difficulty. It's a huge amount of work, that 
> won't earn them any sales, and they really don't even know how to do it if 
> they wanted.
> 
> What makes something accessible? Does it need full keyboard navigation and 
> scripts to automatically make sure that everything is spoken? Is it fair to 
> write scripts for only one screen reader? Who decides which screen reader 
> will be used to evaluate the accessibility?
> 
> Is a program accessible if enough info can be reasoned out with the screen 
> review cursor to make most of the important features accessible?
> 
> Most programmers in the world don't even know what a screen reader is, 
> nevermind how it works, either technically or from a user's perspective. How 
> much time will it take for a given group of programmers to learn how the 
> screen reader gets info off of the screen so that they can at least get to a 
> point where they can dream up a plan of how the might be able to accommodate 
> it after lots of work? Who will help them with technical issues related to 
> accessibility? Will they have to pay a screen reader manufacturer or 
> Microsoft for consulting assistance, and where will that money come from? How 
> will the programmers learn how to operate the screen reader enough to be able 
> to experiment with using it to examine what their program looks like to the 
> screen reader?
> 
> One thing that Apple got right was the design of the way that assistive tech, 
> like a screen reader, interacts with programs. If a Mac program isn't 
> accessible, then there are clear directions to follow for a programmer to fix 
> it. The changes involve adding extra bits to their program that essentially 
> explain to VoiceOver how to read a particular control to the user. The 
> programmer doesn't need to know how screen readers work at all. They just 
> follow the directions to expose the appropriate info. They don't even need to 
> change how their program appears visually.
> 
> On Windows, when blind people ask for accessibility, they usually don't know 
> much more than the programmers as to what is technically involved in making 
> something accessible. I hear people frequently ask for standard Windows 
> controls, but that is like asking web sites to show everything in black and 
> white with no color, no background, no icons, and no substantial formatting. 
> Appearance/theming/skinning is part of a program's image/brand, and, for 
> complex software, is chosen to make it easier to visually understand how to 
> work it. If you ask a company that makes a product like that to use only 
> standard Windows controls, in their minds, you might as well have asked them 
> to write a DOS version. They aren't going to destroy the look-and-feel that 
> sighted people recognize in screen shots from the web and YouTube. No way.
> 
> Some small software shops might tweak their programs to use standard 
> controls, or at least write text on the screen in a way that a screen reader 
> can recognize with its screen review cursor, but, in many cases, these are 1 
> or 2 man projects that didn't use a lot of custom design in the first place, 
> not to help blind people, but because they couldn't afford the time to make 
> something that looks as slick as the professional program that they're 
> competing against. They also probably just run on a single platform, like a 
> VST version for Windows.
> 
> Native Instruments directly draws everything. They don't use any operating 
> system features for their user interface if they can at all help it. They 
> have designed a system that their plug ins can use to display the same 
> interface, regardless if it is running on Windows or Mac. They don't have 
> time to make a version that is just for one OS and its user interface qwerks. 
> They sell lots of synths directly, and they must create DXI, VST 2/3, RTAS, 
> and Re-wire versions for Windows, as well as VST, AU, RTAS, and others for 
> Mac. In some cases, each of the above has to have a 32 and 64 bit version. 
> Further, many companies sell products built on their sampler platforms like 
> Kontakt, and those people need to be able to create a single version, and 
> have it run in all of those formats, and on Windows and Mac. That's why they 
> make their own generic user interface that has nothing to do with Windows or 
> Mac OS.
> 
> That might seem like they could fix it in one place and be fine, but it isn't 
> that simple. If they change the code that renders the UI, then they have to 
> go through a long process of testing it on multiple formats and OSes to be 
> sure that one of their products doesn't react strangely now. All might seem 
> fine, until they get reports that the 64-bit RTAS version ofone of the plugs 
> is not displaying correctly, but only on Mac. All of their partner developers 
> that build on Kontakt will also have to re-test. Most of them use Kontakt and 
> the like so that they don't have to be expert programmers with multiple 
> formats and operating systems, but a radical redesign of the user interface 
> rendering code means that they must re-test everything everywhere, to be sure 
> no surprises pop up.
> 
> It is a technically complex process, will require lots of money to study and 
> then fix, and lots of people involved don't care to create work and expense 
> for themselves, or alienate customers, by fixing what they don't consider is 
> broken. To make it happen, you must be able to supply some clear idea of what 
> must be technically accomplished, and where the people and money will come 
> from to fix it. Even then, the project managers won't want to take on new 
> projects that will put them behind schedule, the developers won't want the 
> added work and bugs, the sales people won't want to upset the partner 
> developers, the partner developers will resent the required money and time 
> that is being asked of them, and upper management will want to know why we're 
> spending all of this money on something that is distracting us from finishing 
> the version that we need to put out on schedule if we're going to meet 
> earnings estimates this year.
> 
> If it was a quick and simple fix, no one would mind. For them to do anything, 
> though, is a major technical project. I'd like to use their stuff, but I 
> realize why it isn't going to happen. I feel like people just get too worked 
> up over Native Instruments.
> 
> There are choices. If you are really doing this for a living, then you're 
> earning good money, and you can pay what it costs to put together the sort of 
> solution that will allow you to compose with these sorts of sounds. That's 
> what sighted composers do, so it isn't like you're having to pay that much 
> more to be able to still accomplish this sort of goal if you're blind. If 
> it's just a hobby for you, and you aren't rich enough to drop $30,000+ on a 
> hobby, then, what can I say, the only alternative is to make the best of the 
> alternatives, while everyone else waits for Native Instruments to care. Maybe 
> you can compose with a library that you can use, and sub-contract to someone 
> else with the pro libraries to arrange/mix it for you.
> 
> Bryan
> 
> On Jul 7, 2011, at 10:59 AM, <ivanlopez@xxxxxxxxxxx> <ivanlopez@xxxxxxxxxxx> 
> wrote:
> 
>> I am hearing folks say at least three different things regarding making
>> software blind user friendly: If some companies do not make blind user
>> software on the basis of difficulty, that is one thing, if they donâ•˙t
>> do it on the basis of misinformation, that is another, and if they
>> donâ•˙t do it because it is something they can do but they just donâ•˙t
>> want to do it, that is another.
>> 
>> For reason one, acceptance of the temporary dilemma is viable, for the
>> second, as someone pointed out, if we blind folks know it will be an
>> easy fix, lets educate the companies, if the 3rd is the reality, we
>> might want to consider a civil rights rout.
>> 
>> However, it looks like there is lots of speculation with the reality we
>> are facing: are companies really not making their software user friendly
>> because it is difficult? Are the companies not making their software
>> accessible because they need more information because they lack
>> expertise? Or are they not doing it on the basis of arbitrary or
>> capricious action? Who really knows? I donâ•˙t
>> 
>> -------- Original Message --------
>>> Subject: [ddots-l] Re: Native instruments?
>>> From: Chris Smart <csmart8@xxxxxxxxx>
>>> Date: Thu, July 07, 2011 7:09 am
>>> To: ddots-l@xxxxxxxxxxxxx
>>> 
>>> 
>>> At 08:08 AM 7/7/2011, you wrote:
>>>> I think that a lot of companies think that making a piece of 
>>>> software accessible will require a complete reworking of the 
>>>> gui.  There are much easier and more reliable ways of making 
>>>> programs accessible these days.
>>> 
>>> Gord, I write companies regularly about this, but I don't have 
>>> enough facts to make a strong case that will make sense to the 
>>> programming folks.
>>> 
>>> Can you elaborate on some of these methods?
>>> 
>>> thanks
>>> Chris
>>> 
>>> PLEASE READ THIS FOOTER AT LEAST ONCE!
>>> To leave the list, click on the immediately following link:
>>> ddots-l-request@xxxxxxxxxxxxx?subject=unsubscribe
>>> If this link doesn't work then send a message to:
>>> ddots-l-request@xxxxxxxxxxxxx
>>> and in the Subject line type
>>> unsubscribe
>>> For other list commands such as vacation mode, 
>>> click on the immediately following link:
>>> ddots-l-request@xxxxxxxxxxxxx?subject=faq or
>>> send a message, to 
>>> ddots-l-request@xxxxxxxxxxxxx
>>> and in the Subject line type
>>> faq
>> 
>> PLEASE READ THIS FOOTER AT LEAST ONCE!
>> To leave the list, click on the immediately following link:
>> ddots-l-request@xxxxxxxxxxxxx?subject=subscribe
>> If this link doesn't work then send a message to:
>> ddots-l-request@xxxxxxxxxxxxx
>> and in the Subject line type
>> unsubscribe
>> For other list commands such as vacation mode, 
>> click on the immediately following link:
>> ddots-l-request@xxxxxxxxxxxxx?subjectï¿∏q or
>> send a message, to 
>> ddots-l-request@xxxxxxxxxxxxx
>> and in the Subject line type
>> faq
>> 
> 
> PLEASE READ THIS FOOTER AT LEAST ONCE!
> To leave the list, click on the immediately following link:
> ddots-l-request@xxxxxxxxxxxxx?subject=unsubscribe
> If this link doesn't work then send a message to:
> ddots-l-request@xxxxxxxxxxxxx
> and in the Subject line type
> º{.nÇ+For other list commands such as vacation mode, 
> click on the immediately following link:
> ddots-l-request@xxxxxxxxxxxxx?subject=faq or
> send a message, to 
> ddots-l-request@xxxxxxxxxxxxx
> and in the Subject line type
> ≈·ƒj

PLEASE READ THIS FOOTER AT LEAST ONCE!
To leave the list, click on the immediately following link:
ddots-l-request@xxxxxxxxxxxxx?subject=unsubscribe
If this link doesn't work then send a message to:
ddots-l-request@xxxxxxxxxxxxx
and in the Subject line type
unsubscribe
For other list commands such as vacation mode,
click on the immediately following link:
ddots-l-request@xxxxxxxxxxxxx?subject�q or
send a message, to
ddots-l-request@xxxxxxxxxxxxx
and in the Subject line type
faq

Other related posts: