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.
