Header Image

Archive for Editorials

★ Xcode Accessibility

This week, AppleVis posted an open letter to Apple, regarding the accessibility of its Xcode IDE. As someone who uses Xcode on a daily basis, I wanted to draw some attention to this effort and comment on a few aspects of it.

On the whole, I agree that Xcode could be improved in several key areas, most notably Interface Builder, in the way that it interacts with VoiceOver. There are definitely issues that must be worked around when developing software with it, and I very much want to see Apple address these issues. So, I applaud the writing of this letter. Whether or not open letters are an effective way of encouraging change is another matter entirely.

In their desire to hammer home some important points, some other, also very important, items were omitted from the letter, and I fear these omissions will potentially result in two unintended side effects. The first, and most damaging, is that they will discourage visually impaired coders from trying out Xcode at all. The second is that by omitting certain details, they may inadvertently cause their letter not to be taken seriously.

Since this is an important issue that effects all developers who use VoiceOver to access Xcode, I want to add my own thoughts to this discussion.

History

I’ve been using Xcode since version 3. While there is still quite a lot of room for improvement, it should be noted that we’ve come an extraordinarily long way since then in terms of accessibility. It was, in fact, entirely impossible to use Interface Builder in those days. Now, though cumbersome for some tasks, it is at least possible.

When Xcode 4 came along, the UI was entirely revamped. For a VoiceOver user, it was a mess of hundreds, perhaps thousands, of controls all crammed into a never ending sea in the Xcode main window. It was extremely difficult to use, and more than a little overwhelming. Over the next couple of point releases, a tremendous amount of accessibility work was done, and the interface became immeasurably more VoiceOver friendly, thanks in part to the logical organization of related controls into groups.

Since then, most, if not all, updates to Xcode have provided improvements to accessibility. Xcode 6 has continued this trend. Many controls that VoiceOver reported as simply “unknown” now have accessibility labels, making them easier to identify. Not all of these labels are terribly intuitive, at least not to me, so there is still room to improve in this regard, but it is yet another step forward in the right direction.

Tools

All screen readers, regardless of platform, have a variety of tools at their disposal for dealing with difficult situations. Jaws for Windows relies heavily on scripts and configurations, Window-Eyes uses scripts and set files, and VoiceOver relies on Activities and scripts. In broad strokes, all of these strategies are similar, though the details can vary widely between screen readers.

Some of the scenarios described in the open letter can be improved upon by using the tools made available by either VoiceOver or Xcode. HotSpots, in particular, can drastically minimize the amount of navigating and interacting required to perform common tasks in Xcode. I know, because I use this technique everyday. Setting VoiceOver HotSpots to the various group views in Xcode not only moves you immediately to that group if it is visible on the screen, but it also automatically interacts with it.

Navigation can also be sped up by judicious use of VoiceOver’s Trackpad Commander. This does, however, require you make yourself familiar with the layout of the various views in Xcode.

Xcode itself has enumerable hotkeys and tricks for increasing efficiency. Some of these are readily obvious in the UI, and some take some digging to discover. For instance, Control-Command-Up/Down arrows can jump you quickly between related header and source files. Command-L allows you to jump to any line number of the current file.

Connecting interface elements to code is hands down the most cumbersome task for VoiceOver users, but if performed correctly, I’ve found it to work extremely consistently. I have received many emails and tweets about this aspect of the process, and in almost every case, the system did not work for one of two reasons: either the user was missing a step, or else they were trying to connect an element to an object that it could not be connected to. That latter is particularly problematic, because in OS X development, controls are permitted to be connected to the AppDelegate. In iOS, they are not, and must typically be connected to a ViewController. If you try to connect, for instance, a button to the AppDelegate in an iOS project, nothing happens, as it shouldn’t. In the case of users who have missed a step, this is illustrative of the cumbersome nature of the task, and shows why the process needs to be improved upon.

Finally, while I have not found the “busy” problem to be quite as bad as implied in the AppleVis letter, it can be largely mitigated by using the VoiceOver option to eliminate Cursor Tracking. (VO-Shift-F3). This is admittedly not ideal, and this is an area I would like to see improved upon across OS X, both in Apple’s apps and third-party apps. The one area where it becomes a serious issue is in the Library group, but turning off Cursor Tracking eliminates the problem.

Wrap Up

Apple can, and should, continue to improve the accessibility of Xcode for VoiceOver users. There is a lot of room for improvement, and hopefully open letters, like the one posted by AppleVis, will draw more attention to the fact that there are a growing number of VoiceOver users who will benefit from said improvements. To imply that they have not been paying attention to this problem, however, is an assertion that is not upheld by the history of the product.

If more VoiceOver users embrace Xcode as a development platform, we can have, collectively, a stronger voice to influence change, especially in this more open era that Apple seems to be moving into. We should not, however, avoid making use of the accessibility tools at our disposal, or, however inadvertently, discourage VoiceOver users from learning to use Xcode as it is today. We need more users to strengthen our case to Apple. The more of us there are, the higher a priority these issues can be given. Engineering resources are not infinite.

Let’s discuss the problems of using Xcode with VoiceOver; let’s try to affect change; but let’s also be encouraging users to utilize all the tools and tricks at their disposal as well.

Xcode has come a long way since version 3. Here’s hoping Apple continues to push accessibility forward for VoiceOver users in its development tools.

★ A First Look at VoiceOver in iOS 6

Apple’s sixth major release of iOS has finally arrived. Along with the scores of new features for users of all stripes come changes and enhancements to the mobile operating system’s accessibility features, including VoiceOver.

This article is not meant to be an exhaustive list of everything that has changed in iOS 6. Instead, it should provide highlights of some of the most interesting additions and enhancements to the system’s accessibility feature set.

Although iOS 6 is available on the iPad 2, 3rd-generation iPad, iPhone 3GS, iPhone 4, and iPhone 4S, as well as Apple’s forthcoming iPhone 5, not all features are available on all devices. We will try to clarify when a feature being discussed is not available on all devices.

Let’s take a look at iOS 6. » Read more..

★ A Look at Accessibility and VoiceOver in iOS 5

As is our custom at Mac-cessibility, we won’t be covering the more general enhancements and additions to the iOS operating system which powers Apple’s mobile devices in this review. While some of the new features will certainly be relevant to our discussion, we’re going to be primarily focussing on what’s new in terms of accessibility, especially where regards VoiceOver.

A Note on Timing

A few people have asked us why we waited so long to publish our review of iOS 5 and the new features found in VoiceOver. The fact is that any users publishing reviews, blogs, and additional information on iOS 5 and the new VoiceOver features prior to 12/October/2011, beyond that which Apple has specifically released, are doing so in violation of Apple’s Non-Disclosure Agreement (NDA), which they had to accept before gaining access to the software. We at Mac-cessibility believe that such violations show a lack of respect to Apple, and most especially to the developers who comprise the VoiceOver team. We, therefore, will never publish details of Apple’s products before embargoes are lifted, nor will we provide links to sites which publish such content, unless the information comes straight from Apple itself.

» Read more..

★ The Lives He Touched…

Louis Braille…Helen Keller…Steve Jobs…

If that list seems incongruous, it isn’t. There are few throughout history who have had as profound an impact on the lives of the visually impaired as Steve Jobs.

He wasn’t an engineer, or a scientist, or a mathematician. He was, at his core, a man who saw beyond the limitations of the present to the possibilities of the future, and how that future could, and in fact should, be inclusive to all, regardless of an individual’s limitations or abilities.

A few of those who have contributed to this site over the years have shared their thoughts on the loss of Steve Jobs. The pieces below do not try to tell a cohesive story. They are meant only to offer a glimpse into the lives of a handful of individuals among the multitudes whom Steve Jobs’s vision touched.

» Read more..

★ Crossroads: Rekindling the Accessible Ebook Discussion

A few weeks ago, I read a question posed by someone on Twitter that rekindled a line of thought I have had on and off for a couple of years. In essence, the question was this: "We have BookShare.org, the National Library Service, and other similar resources. Why should we care about the accessibility of eBook platforms like iBooks, Kindle, Adobe Digital Editions, etc?"

On the surface, this question, which has been posed by several people with whom I’ve been acquainted, appears to be a pragmatic one. If one digs a little deeper, however, it becomes an illustration of an alarming attitude, often an unconscious one, throughout the visually impaired community.

Before exploring that aspect, though, let’s take a quick look at just a few of the strictly practical answers that can be given to this question.

» Read more..