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.
