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 >> >
