If you want to build a fully-fledged, cross-platform desktop application, with built-in web client and support for HTTP, would it make more sense to build it in Java, say, than Javascript running in a web browser? You’d get all that access to OS features that you don’t get from the browser.

Re. the iPhone or iPod for a blind user, Stevie Wonder mentioned that in a recent BBC interview. I gather that he uses an iPod.

Firstly, comparing the output of Cappuccino to a desktop app, but then attempting to paint them with the same accessibility brush is a bit poor. The fact is that Windows and OS X have excellent accessibility layers already built in, and that circumventing these layers is quite difficult if you use the standard APIs (Cocoa and whatever Windows is using these days), as the buttons, scrollbars etc. that come with it already have this functionality baked in.

It occurs to me that this is both the blessing and the curse of CSS and Javascript–for all we bitch and moan about their limitations that allow us virtually unlimited freedom to make things in a browser look like anything else, something that’s almost impossible to do in desktop apps without great productivity and future-proofing loss. Hence, one *could* make a DIV look like a BUTTON or vice-versa. The issue, though, is that a DIV is *not* a button, and does not look like a button to the underlying systems. And at the core of it, this is the issue.

Using non-standard widgets and controls in web applications essentially means you’re divorcing yourself from the baked in layer of accessibility that all modern operating systems ship with. This is true for blind users, movement-impaired users (try tabbing to a DIV or SPAN just using the keyboard), users who need to scale fonts up (like my grandfather), etc.

Don’t get me wrong, I think Cappuccino is a fantastic technical accomplishment, and you should be praised for getting it this far and as polished as it is. You’ve been very accepting of and gracious towards what could easily have turned into one of the regular Internet lynch mobs that seem to crop up every time web standards is debated.

That said, now that it’s in the wild, it’s time to face some of the truths about the Internet as a whole–unless you’re building a truly walled garden (an Intranet comes to mind, although that said we had at least two blind employees I knew of at Yahoo!, where I used to work) you cannot *ever* guarantee your audience’s capabilities, and you need to make your application the most broadly accepting possible. That in my mind is the key to user experience and quality web development.

You’ve demonstrated yourself to be a great listener and a very reasonable person, so I hope someone with solid knowledge of ARIA steps up to help you guys out, as I think we’d all love for truly rich interfaces to be as inclusive as we’ve tried to make the rest of the Internet be.

I don’t know much about the Cappuccino and what you are building, but I hope you take accessibility in mind. Besides building screen-reader friendly interfaces for the more profoundly blind, building for those of us with functional vision is important. Thinking about font scalability with zoom and good color schemes with sufficient contrast is key, Reducing clutter helps too.

Best of luck with your project.

Ps looks like you need a fireman for all the unnecessary flames.

Operating systems have had accessibility aids long, long before the web even considered it. Don’t forget that most browsers barely touch on providing an aid whereas OSes do it as standard for any programs.

The entire API in an operating system is designed to work with this. It’s only when you start hacking around APIs and writing proprietary machine code you start to break accessibility in desktop apps. It’s especially hard to break this on OSX.

Hence, you can build it in later in many apps, or enhance it. Unfortunately with web apps this is not the case and so it is up to you as a developer to use good sense when building. You have to make sure that it doesn’t depend on any single input. And yes, you do have to replicate behaviours server side and client side to make it work well.

If something is abstracted sufficiently so it can work with a variety of inputs or configurations (MVC will do this, but there’s plenty of other ways) then accessibility will come naturally to the app. If you don’t do this from the start, it is very, very hard to implement later, hence my comment.

I wouldn’t want to start having to modify Cappuccino to work with x y and z – it would be quicker to do a ground up rewrite on parts.

Through and through I am a developer and by trade a UX guy. I am all about accessibility because it defines an app being usable by someone who is able as well as DISabled. If it’s not accessible it by definition doesn’t actually work.

Again, for some reason (blame 37signals for spouting their tables shit, I guess) this whole ‘accessibility compromise’ chat seems to be the in thing online right now. It isn’t right.

On the one hand you say you WANT to put accessibility into this (and I wish you luck, wouldn’t want to be you!) but on the other you argue that a mass market device, hell an FMCG isn’t accessible but sells loads? Well, yes, of course it does, because it’s a mass market device. There’s a lot of more able people…. The key is the percentage of disabled users, and also, if this is a good proportion, how they adapted. iPod is a bad example as it works on ‘clicks’ which inherently gives it an advantage so I presume it doesn’t do too badly in the disabled world.

So saying you want to change, but arguing why it’s not needed is not really filling me with confidence that it’ll ever be much more than what it is.

I’m off my soapbox now…

No, they should not! Wait…

I’m not sure why the only valid approach is accessibility “from the ground up”. If that were the case, then Mac OS X would have shipped three years later, Adium would never have shipped, neither would Twitterific, or the first version of Safari, or the iPhone and the iPod, or pretty much any of the apps I use on a daily basis.

Creating something completely new is challenging, and you can’t solve every problem at once. More importantly, as I stated, there was simply NO route to semi-dynamic accessibility in the browser until ARIA which has only been a factor in the last year or so. And if the real goal here is accessibility, why is 2009 too late? Why would anytime be too late?

If I’m coming across as lazy and rude, you are coming across as someone for whom the only relevant issue in all of software engineering is accessibility. Can’t we find some middle ground?

So to me this reads: I’m not going to learn how to do accessibility in web apps, which has been talked about in the mainstream for something in the region of 7+ years, I’m going to get someone else to do it for me. You may not intend to say this but many who do contribute to code bases find this somewhat rude.

That’s what to me, makes no sense. Surely, if this is so bleeding edge as Carson and his ‘contemporaries’ shout, it should have accessibility from the ground up. Otherwise it’s just another very fancy, but ultimately outdated and incomplete app. Heck, why let people like Carson shout so loud blindly ignoring any of the current issues when it’s not ready for showtime. IMHO the acknowledgment of the ‘need’ for accessibility should have been more upfront, otherwise it just seems to be an elaborate ad for 280.

We’re not going to have a mature accessibility set for a long time so you have to work with the confines you are given, like any self respecting coder who invests in accessibility.

Why was it so hard to make Cappuccino accessible from the start? There should always be a base model that ‘works’ on a basic level, which you then enhance upwards. I appreciate it was not in your school of thought then but bolting this stuff on in 2009 is a little late IMHO.