And that my friend is the billion dollar question which the only way I could atempt to even explain is maybe ITunes is garbage? *grins* no really, I have no answer for that and I don't think anyone can. I guess for those who like it, it would be nice for them to be able to use it but its not a selling point on the mac for me. I use my mac for more important stuff than downloading and purchasing music. go buy a windows box with napster or something if that is what you use your mac for. the mac is a computer not a juke box. Gabe Vega The BlindTechs Network Website: http://blindtechs.net Email: [EMAIL PROTECTED] (602) 476-2307 (562) 261-5277 (866) 714-4244 ----- Original Message ----- From: "Dan Keys" <[EMAIL PROTECTED]> To: "General discussions on all topics relating to the use of Mac OS X by the blind" <[email protected]> Sent: Sunday, September 10, 2006 8:55 PM Subject: Re: voiceover, a talking interface:
> Hello, > I agree with all you have stated. However, this begs the question. If > Native Applications in Cocoe should be accessible, why is not Apple's > own flagship programs like iTunes not truly VoiceOver accessible. > > On Sep 10, 2006, at 7:58 PM, Kafka's Daytime wrote: > > > 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. > >> > >> > >> > > > > > > >
