Yeh. All true. I don't seeing this situation change on computers, or the real world, any time soon, though. However, the lag between the general public version, and any adaptations to meet our needs, Is shorter today than in the past. On some fronts, there is no lag at all.
Your best defense are options. True, the new Mobile Me doesn't work so well with Safari and VoiceOver. In fact, VoiceOver isn't working that well with Safari on some Macs with the latest OS. However, I can use Mobile Me just fine with Windows browsers and screen readers. In terms of the web, some sites work better on Windows, while some read better on the Mac. I have VMWare, so can run them all on one computer. I don't need to be stopped when Safari won't work with a page. I have Firefox and Internet Explorer, either through Jaws, Window Eyes, and others to assist. Sometimes options aren't as affordable. You can't edit MIDI events in Pro Tools, but, if you absolutely had to do that for a particular project, you could always use Sonar. Options aren't the easiest or most affordable way to live, but at least you'll be making progress while others stand still waiting on a fix. Bryan -----Original Message----- From: ptaccess@googlegroups.com [mailto:ptacc...@googlegroups.com] On Behalf Of Scott Chesworth Sent: Wednesday, June 30, 2010 11:36 AM To: ptaccess@googlegroups.com Subject: Re: Update Summer 2010 GB illustrates the point better than Logic I guess in this case, because it doesn't predate VO or have Logic's development history. Again, I guess I was hoping that when Apple took their stance they'd break the cycle, and then even if nobody else followed suit we'd be in a more stable position, even if we wouldn't yet have the amount of choice that average Joe the recording rookie does. GB isn't the only example of course. Emails from Apple's own accessibility address saying "at this time, we aren't recommending VoiceOver users purchase MobileMe accounts" post-launch indicate that this particular cycle is running on a fresh set of pimped up wheels and has plenty of miles left in it yet... ugh. I love their UI's when they work though, so I'll suck it up and wait. On 6/30/10, Bryan Smart <bryansm...@bryansmart.com> wrote: > 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 >> >
