On Tuesday, we announced Atlas, our new visual layout tool for Cappuccino. I’m incredibly excited about where Atlas is headed, and I’m also glad to hear all the feedback we’ve been getting just from our demo video. One of the things in particular that I’ve read several discussion on is accessibility and Cappuccino, and I wanted to share some thoughts on the topic.

Drew McLellan wrote an interesting piece outlining his concerns about the subject, but I think certain things need to be clarified. First, there’s a difference between accessibility and the availability of JavaScript. Accessibility is about enabling assistive technologies like screen readers to relay information to users with disabilities like vision impairment. JavaScript availability, on the other hand, is about whether or not a user’s browser has JavaScript enabled (or supports JavaScript at all). JavaScript availability is what people are talking about when they talk about graceful degradation. Both of these issues are important, but they need to be addressed separately.

Let me state the obvious: JavaScript availability is a requirement for writing an application in the browser. The reason is simple, writing a program requires a programming language, which HTML and CSS are not. To be more precise, I’m talking about an application that doesn’t rely on the server for all its logic, a truly browser based application, not a website with a dynamic back end. Not all programs should be or need to be written this way, that is something we readily acknowledge. But, some applications only make sense written like this: a presentation editor can’t hit the server on every single move or update or reposition of a slide element; a word processor can’t hit the server every time you need to type a character. I don’t believe this is a controversial statement, it’s a fundamental reality of the web. And it’s something you see not just in Cappuccino, but in any complex web application, from Google’s to Apple’s and countless others.

The second issue is accessibility, and I do believe its important. First, to put on my contrarian hat, you have to consider that not all applications can be made accessible. Although I could be wrong, I don’t think there’s a reasonable way to make Photoshop accessible to someone who can’t see; fundamentally it’s a visual tool. 280 Slides, for the most part, is the same (and to a large extent, Atlas may be as well). They are largely visual tools, heavily relying on visual design, drag and drop, and other mouse based metaphors. Since Cappuccino development up to this point has been driven mostly by our own needs, that may help explain why this hasn’t been a top priority for us.

All that aside, we absolutely want Cappuccino to be an accessible platform. Until pretty recently, this just wasn’t a possibility. Browser vendors and assistive technology vendors provided absolutely no facilities for interacting with the accessibility system. We’ve been working on Cappuccino for some time now, and I think it would be a travesty if none of the things we’ve accomplished had been done simply because there wasn’t yet a way to make them accessible. Cappuccino is pushing the edges of web development right now, and understandably some things take time to catch up. Vendors need to take their share of responsibility for the problem.

More recently, efforts like WAI ARIA are starting to be taken seriously enough to consider as a potential avenue for Cappuccino. Like the rest of our APIs, we have a strong foundation to build upon — Mac OS X has great support for accessibility in custom UI. I am extremely excited about integrating some of these technologies into Cappuccino. At the same time, 280 North is a three person company, developing our own products to support our business, and developing Cappuccino in the open to benefit everyone. We can’t program every feature needed in Cappuccino all at once, but that’s part of why we’re embracing open source. If people feel strongly about WAI ARIA, I encourage them to get in touch with us about helping to add support to Cappuccino. It isn’t an area we have a great deal of expertise in, but we’re happy to learn new things, and this is absolutely a problem we want to work on.

As for Atlas, I’m looking forward to sharing more about development status, and what it can do. We’ve got a lot of ideas, but we really love hearing what fellow developers feel is important. This is just one good example of the feedback we’ve been getting, and hopefully I’ll be able to share more in the coming months.

An iPhone application I wrote just got posted to the app store yesterday. iReddit (cleverly named huh?) is the official reddit client for the iPhone. I may have built the iPhone app, but they built reddit, which is the really hard part, and for that we’re all thankful.

Actually, I’ve been interested in trying out the iPhone dev environment for some time. I got to talking with Alexis and thought this would be a great opportunity to build something useful, and help out our startup at the same time. All in all it was a good experience, but at times the iPhone dev process may make you want to kill yourself (and not because of the programming part). Don’t say I didn’t warn you.

The app itself is pretty great. You can browse the combined front page, or look at individual subreddits, and even get your own customized reddit list on the phone by logging in. Commenting, voting, and saving are all there, plus “serendipity” mode, which displays a random upcoming reddit story every time you shake the iPhone. The best part of the app is probably the reddit alien getting pissed off at slow loading pages. The effect is great.

So, if you haven’t already, go buy the app! I’ll try and write more about the dev process in future posts, and in particular about my take on the app store and some of the things people have been complaining about.

Alexis has a bit of a crazy side to him, and it called him to make this commercial for the app. Hand modeling by yours truly. Still waiting to hear what Wil Wheaton actually thinks of it.