Subject: [ddots-l] Re: Are we speculating or do we know what is really
happening?
From: "Omar Binno" <omarbinno@xxxxxxxxx>
Date: Fri, July 08, 2011 3:37 pm
To: <ddots-l@xxxxxxxxxxxxx>
Darren,
I agree with you, except the only problem is that it seems that a lot of
other companies make products that only use the kontakt player from ni.
----- Original Message -----
From: "Darren" <darren@xxxxxxxxxxxxx>
To: <ddots-l@xxxxxxxxxxxxx>
Sent: Friday, July 08, 2011 4:25 PM
Subject: [ddots-l] Re: Are we speculating or do we know what is really
happening?
This is why I love spectrasonics products.
Not only are they top draw products, they are able to be made accessible
to
a fair degree with HSC.
I believe Window Eyes also has an HSC equivalent.
In all honesty, I've not heard anything from Native Instruments that I
haven't been able to find elsewhere from other companies.
Just because everyone's using it, doesn't mean it's good. It just means
there are a lot of sheep.
Cheers
Darren
-----Original Message-----
From: ddots-l-bounce@xxxxxxxxxxxxx [mailto:ddots-l-bounce@xxxxxxxxxxxxx]
On
Behalf Of Bryan Smart
Sent: 08 July 2011 21:14
To: ddots-l@xxxxxxxxxxxxx
Subject: [ddots-l] Re: Are we speculating or do we know what is really
happening?
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=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?subjectq 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
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
