Absolutely. I only meant to point out that some of the most basic
features
in Logic are surprisingly inaccessible. Please, ProTools, come
quickly.
-----Original Message-----
From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com]
On Behalf
Of Bryan Smart
Sent: Wednesday, June 30, 2010 11:08 AM
To: ptaccess@googlegroups.com
Subject: RE: LogicRE: Update Summer 2010
This is probably a thread for VIMac-Audio or MIDI-Mag, but, in
short, those
settings aren't in preferences. I'll have to go back to look, but
they're
either in the main or mix windows, similar to GB.
Bryan
-----Original Message-----
From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com]
On Behalf
Of Ginny Owens
Sent: Wednesday, June 30, 2010 11:23 AM
To: ptaccess@googlegroups.com
Subject: LogicRE: Update Summer 2010
Bryan,
Speaking of "small parts" of programs where lack of accessibility is
maddening, have you by any chance found a way to turn off the click
during
recording in Logic and to manually set the overall tempo? I'm
using a
control surface to overdub multiple tracks of audio, which is
working fine.
But I can only seem to shut the click up during playback, and since
I can't
set the tempo, well...it's maddening. Lol.
I'm going to try searching through recording settings again, but any
thoughts would be welcome.
-----Original Message-----
From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com]
On Behalf
Of Bryan Smart
Sent: Wednesday, June 30, 2010 10:08 AM
To: ptaccess@googlegroups.com
Subject: RE: Update Summer 2010
Slau already wrote you a great reply. However, I'd like to remind
you, when
it comes to Logic, that Apple purchased that program from EMagic.
They
didn't write it in-house. Beyond that, Logic has been around since
well
before Cocoa. It was a Carbon app first, and ran on the classic Mac
OS
before that. Such programs are bears to reorganize without breaking
everything. And, in the case of Logic, on the whole, it is actually
extremely accessible. So is GarageBand, for that matter. The
infuriating
thing about those apps is that the tiny parts that aren't
accessible are
profoundly crucial. For example, I can work almost everything in
GB, all the
way down to editing effect and synth presets in their native user
interfaces. However, I can't select any recorded data, so can't
edit. No
editing pretty much rules out GB for anything serious. In Logic, I
have a
similarly high level of access, but can't access the part of the
interface
where the mixing console is displayed.
Cocoa does mostly work out of the box. When problems appear, it is
usually
that controls aren't labeled, but VoiceOver can see them, at least.
If you
figure out the purpose of a control, either through trial and
error, or if a
sighted person tells you, it is possible to label the control with
a VO
hotkey. In the inaccessible places of programs, like Logic, those
aren't
even using Cocoa controls. There aren't as many situations on the
Mac where
developers avoid using a standardized toolkit like Cocoa for
appearance
considerations, as is common on Windows. Cocoa applications can
replace the
look and feel of a standard Cocoa control (like a button), while
retaining
all of the built-in functionality. On Windows, if you want a button
that has
custom 3D effects when you press it, so to make your software
synthesizer
look like a real synth, your only choice is to reinvent the wheel.
With
Cocoa, you can replace just the part of the button that handles how
it is
drawn. No developer wants to reinvent the wheel if it isn't
necessary, so
most of them use Cocoa, and tweak it for their needs. A developer
making
their own custom button, like above, might draw the label on the
button. In
that case, they might skip setting the title attribute on the
button, so VO
wouldn't be able to tell you the name of the button. It still could,
however, tell you that there is a button, and it can press it. No
problem,
though. You can set a custom label for that button, or, if someone
has
already set such a label, they can share it with you.
Bryan
-----Original Message-----
From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com]
On Behalf
Of Scott Chesworth
Sent: Wednesday, June 30, 2010 9:41 AM
To: ptaccess@googlegroups.com
Subject: Re: Update Summer 2010
Hey Brian,
Sure, I know enough to understand why the accessibility wasn't
present in OS
X for so long, and can certainly appreciate that with an app as
vast as PT
with the client base it has, an interface rewrite is a huge
undertaking that
would have to roll out gradually. I suppose the concern stems from
hearing
that the guy Avid hired initially worked on accessibility
specifically for a
period. What that makes me wonder is, was he manually exposing
areas of the
UI that were still Carbon-based for us so that we'd have the key
components
of the app available, or was he going through and playing catch up
with the
parts of the UI that other coders had already rewritten in Cocoa.
If it's
the former then I'm likely worrying over nothing, but if it's the
latter,
and this chap who was a temp at Avid was the only person who had a
firm
grasp of Apple's accessibility documentation, then surely the
process would
need to be repeated and accessibility will appear in chunks at that
point
rather than happening automagically as Avid update their UI. I'm
not a
developer by any stretch of the imagination, so I don't know how
accurate
Apple's whole "Cocoa just works with VO out of the box" line really
is, but
I'd feel a lot more confident about the future if every Cocoa-based
app I'd
ever downloaded worked like a charm (which it hasn't), or even if
Apple's
own product line was playing ball by now (which it isn't).
I dunno, perhaps I'm hypersensitive and overanalysing because I had
some
momentum and something that appeared to be a career developing last
time
around. It gradually had to grind to a halt because lugging around
my own
outdated gear and dumping it in the midst of every session wasn't
always an
option. I don't want to be in that situation all over again man.
Scott
On 6/30/10, Bryan Smart <bryansm...@bryansmart.com> wrote:
I don't think that you need to worry.
I'm not sure how much of all the future plans and such are
supposed to
be discussed on this list, but Avid is involved in a long term
plan to
update their user interface. Part of the accessibility problem was
that the interface was created using Carbon, and was originally
created early on in OS X days, before there even were the
accessibility features for Carbon, and certainly way before Cocoa
was
available. They're updating their interface for lots of reasons that
don't even have to do with accessibility. As the interface is
modernized, VO users naturally receive many benefits. As they go
forward, there will be less and less of a need for them to do
anything
special for VO users.
Bryan
-----Original Message-----
From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com]
On
Behalf Of Scott Chesworth
Sent: Wednesday, June 30, 2010 4:20 AM
To: ptaccess@googlegroups.com
Subject: Re: Update Summer 2010
The word "feature" and "accessibility" in the same sentence always
makes me uneasy. No, I wouldn't expect Avid to have a VO guru on
hand
to figure out the most efficient workflow for me to get something
done, just like I don't expect every support techie to have the
knowledge to instantly switch off the "drag and drop" terminology in
his script every time I call Apple, but if a task isn't achievable
via
the keyboard or isn't achievable with VO due to elements not being
exposed or being incorrectly defined etc, surely it's not
unreasonable
to expect acknowledgement and response to that. In most cases it
would
after all, be an issue that could be fixed with no specialist
knowledge of anything more than Apple's developer guidelines. I
suppose what I'm getting at is this. VO support not being publicly
stated (even the current partial VO support puts them ahead of the
game compared to Apple
themselves) makes me uneasy that we're not going to be publicly
acknowledged as a userbase either. So, if that's the case, what
happens about new features or interface tweaks from here on in? As I
said, I totally agree that Avid implementing Apple's accessibility
guidelines is the most that we could expect from them, and I am
grateful for what's been implemented so far, but consistency is
key to
this being a viable product for VO users to be able to rely upon it
professionally. I have to wonder whether implementing those
guidelines
and ensuring that new features aren't going to be totally beyond
users
of accessibility will be considered as part of the development
cycle,
or whether the best we can expect is playing catch up every few
years.
I'm not intending to knock Avid. It's just this whole notion of
accessibility as a feature really, really bugs me.
On 6/30/10, Slau Halatyn <slauhala...@gmail.com> wrote:
I'm preparing an update for the web site at ProToolsPetition.org.
For
what it's worth, I'll post it here first because it probably won't
post to the web site for another day or two.
Update Summer 2010
It seems that the fruits of many people's labor are finally
beginning
to show. After years of interfacing with Digidesign, now known as
Avid Technologies, we're seeing the results of our efforts to gain
access to Pro Tools. Changes to the code base of Pro Tools that
make
it easier to navigate the user interface with VoiceOver in OS X
were
implemented in version 8.0.4.
In early June, the HD version was released with the LE and M-
Powered
versions to follow soon.
While there was a great amount of work done to help make Pro Tools
useable with VoiceOver, it is by no means a completed project but
rather a work in progress. While major aspects of the application
are
accessible, there remains some areas that will need to be addressed
in future versions. We always knew that the issue of
accessibility to
Pro Tools would need a long-term solution. We hope to see
improvements to be rolled out over several releases in the coming
years.
Although Avid Technologies has made changes to Pro Tools to
specifically work better with VoiceOver, it has no plans to
announce
it as an official feature, per se. Regarding it as a feature would
imply thorough testing and full customer support from the
perspective
of usability with VoiceOver.
Naturally, one wouldn't expect Avid to troubleshoot issues
regarding
accessibility and the use of a screen reader. Essentially, what
Avid
has done is they've begun to label UI elements according to Apple's
programming guidelines. The rest of the user experience has more to
do with how VoiceOver works and best practices as blind users of
the
operating system and application software.
Again, since this project is still a work in progress, it's still
somewhat experimental as we discover what works and what doesn't.
Although Pro Tools is not yet 100% accessible in all of it's areas,
I'm glad that the work done thus far was included in the 8.0.4
release. It will allow blind users to begin learning the Pro Tools
environment and workflow with plenty of features to explore and
master. In the mean time, Avid is aware of the PTAccess email
list at
GoogleGroups.com and will direct any inquiries from blind users to
the growing community of users in the group. Any issues of
accessibility can be discussed there and any bugs or feature
requests
will be aggregated for future submission to Avid.
I'll continue to post any major updates here but for the latest
information go to http://www.googlegroups.com/group/ptaccess
Slau Halatyn
