Hey Scott, As you know, Pro Tools is cross-platform and, therefore, written in a platform-agnostic language. Currently, when it's split over to the Mac side, it's actually a combination of Carbon and Coco. Actually, it's mostly either Carbon or Coco but, in fact, in the case of the plug-ins window, it's truly a combination of the two in that the parent window is Coco while the child window which displays the parameters is carbon. Even if the plug-in itself is purely Coco, since it's in a carbon window it appears as Carbon.
Although the Coco windows are, as we say, Coco, they're not written in XCode so the UI is not based on Apple's framework so things do have to be manually identified as buttons, checkboxes, etc. Thing is, once these elements are identified, they don't have to be re-defined throughout the application. Sometimes, however, there may be a button which is seen as a button but has no associated text. This doesn't happen much in Pro Tools although there seem to be a few sort of ghost buttons in a few dialog boxes which I'm still trying to understand. they cause no issues so I simply ignore them for now. There are areas which are a challenge like the Tracks List which appears as sort of a table but it's really not. It's a series of windows placed in a table format but VoiceOver doesn't know what to consider them. The programmer came up with a solution and it's not an ideal solution but it seems to work pretty well for now. Another issue we face is the inability of VoiceOver to support modified clicks. In other words, it's not possible, using VoiceOver, to Option-click using VoiceOver commands. It has to be done with a physical mouse which, to me, is less than ideal. This is, of course, a VoiceOver issue that needs to be addressed with Apple. Anyway, as I mentioned in a reply to Chris, when LE comes out, I'll post a list of current issues. I'll also probably do some kind of podcast or something demonstrating the navigation and use of Pro Tools with VoiceOver. Slau On Jun 30, 2010, at 9:40 AM, Scott Chesworth wrote: > 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 >>
