For non-programmers like me the prooff of VO's popularity will depend upon
how many applications can be used by VO users. In other words the proof is
in the eating of the pudding.
----- Original Message -----
From: "Kafka's Daytime" <[EMAIL PROTECTED]>
To: "General discussions on all topics relating to the use of Mac OS X by
theblind" <[email protected]>
Sent: Sunday, September 10, 2006 10:58 PM
Subject: Re: voiceover, a talking interface:
First: *smile* I'm quite certain Yvonne is not going to be thrown off the
list. In fact, Yvonne is to be thanked for bringing us back to an
important discussion which Travis, Bruce, Anne, David, Scott and and
others have visited and revisited.
Here is a response, of sorts, to Yvonne's just-posted comments regarding
developing accessible applications for Mac OS X. If my comments are not
an outright rebuttal perhaps they are an extension of Yvonne's ideas,
some context. Instead of laying it out in straight prose, I'll present
some numbered points...and perhaps this will clear up some commonly-held
misconceptions and lead to more discussion.
Here goes:
1. Apple has standardized application accessibility on Mac OS X. Apple
has done this by making VoiceOver an integral part of the Mac OS and by
exposing/documenting underlying accessibility technologies and providing
all of the required tools to developers (free of charge). VoiceOver is an
alternative interface to the Mac OS as opposed to bolted-on, specialized
access technology (like screen readers on the Windows side). I need not
remind you that VoiceOver is free and available on every Mac.
2. Because of Point 1, any developer - using Apple's free developer tools
and frameworks, builds accessible applications. THESIS ALERT: For the
most part, applications developed in Cocoa (or Carbon - with a few sticky
exceptions there) are - because of the standardized, OS- integrated
approach Apple has taken - *inherently* accessible (with *very* little in
the way of special/specialized effort required). Yes, it's true one needs
to label controls and there are a few extra things that must be done if
one is not using the standard controls...but this is all very low-hanging
fruit (and there are, frankly, good reasons to do this outside of the
accessibility reasons).
3. On Windows, application accessibility - particularly when dealing with
the popular screenreaders - is, in many ways, more alchemy and guesswork
than science...and expensive. It's a mistake to try to understand
VoiceOver as an extrapolation of what we know of Windows screenreading.
You have two very different - perhaps diametrically opposed - approaches.
4. Screenreaders and so-called alternative interfaces exist because not
everyone can access information presented graphically. The real trick is
to make accessibility require less of a special/specialized effort (which
special effort promotes high cost, marginalization, etc.) or individual,
non-standard efforts (laudable though they may be). The screenreading
situation on Windows promotes specialization, marginalization and
high-cost. Accessibility there is special and takes special effort. For
Windows, accessibility is largely an afterthought and not an integral
part of the OS/ On the Mac OS with VoiceOver, however, we're much closer
to a situation in which accessibility does not require much in the way of
special effort, very little in the way of special skills or
knowledge...the OS is inherently accessible, universally designed. Any
application built using "native" Mac OS X tools and technologies (even if
just the front end, a "wrapper", is built using the standard tools viz.
Greg Kearny's DTB production tool) is going to be accessible.
a. Some folks argue that there are more accessible applications
(particularly the specialized, professional applications vis. Pro Tools)
for Windows. These folks are right but they're right for the wrong
reasons. The Mac OS effort is newer but we're starting from scratch,
doing it in a more sustainable and integrated way. Since the effort is
young, not everybody is on board yet. Would you rather a kludgy,
immediate solution (that mirrors what's being done on Windows) or a more
sustainable, integrated solution for the long term which takes a bit of
investment in time, effort and patience at the start? Not an easy
decision, perhaps, but I'll opt for the latter.
5. So, you ask, why aren't all Mac OS X applications accessible then?
Good question.
a. Not all developers have caught up. Some applications need to be re-
written to fit into this new world of standardized Mac OS X
accessibility. All the tools are there (thanks to Apple), there are no
(or few) mysteries...but this takes time. I'm a developer doing one such
rewrite. I challenge you to consider that the wait for updated
applications is not proof of the failure of the VoiceOver approach (or
even unwillingness by developers' to update). There's some retooling on
the developer end of things and that's going to take a little time - but
I'm going to suggest that the vast majority of mainstream Mac developers
see the wisdom in transitioning to the "native" Mac OS X tools and
technologies and are doing it willingly, maybe even eagerly. I know my
life has gotten easier since I started working in Cocoa.
b. Yes, there are still VoiceOver-related bugs and design flaws. *shrug*
That's to be expected. I'm less worried about those since it's just leg
work to fix those and it seems pretty clear that the Apple folks are
committed to doing just that. I'd be much more worried if the overall
approach was flawed. Does everybody get that? This is a big deal...this
inherent, standardized accessibility.
c. Not all developers will choose to develop in Cocoa or Carbon - thereby
inheriting Mac OS X's built in-accessibility. The answer is not for the
Apple folks to try to magically encompass the myriad technologies one
could use to create applications which run on Mac OS X. That's a very bad
idea, it's backwards and will result in the kind of kludgy, bolted-on
solutions you see elsewhere. Make the standard. Provide the tools and
documentation required for meeting the standard and make 'em good. Apple
has done that and (and all the tools are, again, free free free). I don't
have scientific data to support this (and Yvonne's assessments were, of
course, anecdotal as well) but, in my personal experience, the vast
majority of mainstream Mac software developers use these tools happily.
Cocoa (and to a lesser extent, Carbon) is the development framework of
choice for mainstream Mac developers and with that "native" framework"
comes the virtually inherent accessibility we've been discussing.
d. Finally, I don't know any Apple developer (and I know a bunch of 'em)
who *doesn't* like Apple's stock/standard interface (as Yvonne puts it)
or Apple's Human Interface Standards. In fact, Apple appearance and
usability is viewed by some (perhaps many) in the developer community and
elsewhere - as a gold standard. I also don't know of any issues at all
with speed, etc. (as you suggest). If you want your Mac application to
perform optimally, you develop with the Apple tools and frameworks.
They're well-designed, professional-level and free.
e. More specialized tools (like Pro Tools [professional audio production
software] for instance) may take a significant amount of effort to port
(which doesn't take anything at all away from Apple's
approach...sometimes retooling with the "correct" approach, reshaping,
moving forward, means the developer has to bite the bullet, as it were.
That's the life of a developer and I think Apple is right to set the
standard, provide the tools and expect, ultimately, that developers will
join up and play along). It can cost a lot of money/time/resources to
port a big tool (though it would cost exponentially more if Apple hadn't
done so well on its end of things). It's important to let those
developers know that you care about their applications and you care about
those applications being accessible (such an appeal for Pro Tools is
already being organized in exemplary fashion by a member of this list).
Here's the link:
http://www.protoolspetition.org/
My (way more than) $.02,
Joe
On Sep 10, 2006, at 8:49 PM, yvonne thomson wrote:
Hi, all.
As much as I agree with all this, and as much as I love the whole
"talking interface" concept, we all have to admit, surely, that it's not
without its problems.
The main one, as far as I can see, is that it's far, *far* too easy to
make an application inaccessible, and it puts the onus squarely on the
software writer to do the right thing and make it possible for us to use
the software they've written.
As far as I can see, unless the app is stock standard cocoa, you have to
get extremely lucky, or have someone specifically design the app to be
accessible for you. Reality check here, people. Software designers are
absolutely *awful* at this. That, from what I can see, is in part why
screen readers exist. software designers seem to just *hate* whatever
the stock standard interface is. It isn't fast enough. It isn't pretty
enough. It doesn't do what I want and so theay write their own. That's
happened for as long as I've been using computers, and probably longer.
We want it to be cross platform so the toolkit they use isn't read by
Voiceover. And the problem with all of this is, that there's no solution
other than hoping that the writer of the application you want to use
takes pity on you, or just to do what I, at least, have always done.
Decide you want an app to do something, go to a site that catalogs as
much software as possible, and download practically everything in that
category just to find something that works, forget whether it's got the
features you want, worry about that later. First, can we use it at all?
Now please, this isn't to say I'm not loving the Mac, I am. When it
works, it's incredibly easy to use and incredibly accessible, but I
honestly don't think *this* is the silver bullet for us, either. I have
no idea what the heck is, though.
Yvonne who is probably now going to be thrown off the mailing list.
