Accessibility & Degradation in Cappuccino
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.
February 27th, 2009 at 4:40 am
I agree that JavaSCript != accessibility, but I’d be careful about ruling out applications based on ability.
A colleague of mine is blind, and many people will attest that she is a fabulous presenter. She can put together a presentation in powerpoint, and has an audio copy of the text on an audio book if she needs prompting. It might not have whizzy transitions or amazing pictures in it (unless she’s lucky or gets help), but she can do it, and with the basics done her speaking will easily hold an audience.
I also strongly believe that you shouldn’t stop doing something because of accessibility, but that it should influence how you do something. Therefore I hope that you do look carefully at integrating WAI-ARIA with the Framework.
February 28th, 2009 at 2:23 pm
[...] Accessibility & Degradation in Cappuccino [...]
March 1st, 2009 at 12:06 pm
Firstly, congrats and thank you for embracing open source. Way to truly push things forward.
Now I apologize in advance for my ignorance but what steps do you see needing to take place in order to render audio/video apps within the Atlas framework?
March 1st, 2009 at 12:08 pm
There are probably a few different ways this could be done. Better to discuss it on the mailing list or in the IRC channel though.
March 1st, 2009 at 3:08 pm
[...] we can read an article from Ross Boucher (another of the three founders) about accessibility in [...]
March 2nd, 2009 at 1:28 am
Another person who fundamentally misses the point with accessibility. Blindness is not the only disability which needs to be accounted for. Some people, for example, can’t use a mouse.
Suggesting that any app (especially a logical app builder like your own) *needs* specific mouse actions to function is absolutely ridiculous. There are many alternative interface paradigms that can compliment more visual and dexterous UI concepts. What I can do with a mouse I should also be able to do with a keyboard….. and an app builder should do this elegantly. If the app builder isn’t accessible, what the hell is the app it’s spitting out going to be like?!
To suggest that Cappuccino was ‘only built for your needs’ up until now is also slightly bizarre. It’s a public framework and library (although usage seems a little patchy) and you have chosen to display it as that, so you should feel obliged develop it for more than 3 coders sitting in a room around a box of pizza. Heck, even then why on earth isn’t it more universal? Isn’t that just good coding practice?
Cynical me would say you released something half baked to bring profile to your company ASAP, not contribute to a community which is in dire need of a bit more than gaffa tape wrapped round a smashed vase to fix accessibility issues.
Open Source doesn’t really exist just so someone can out of the blue come hack your code to death and try and get it to be accessible. It should be, in this day and age, designed to be accessible from the outset.
March 2nd, 2009 at 2:36 am
JavaScript availability is a requirement for writing an application in the browser.
Heh. You crazy kids! Next you’ll be telling us that punk is the only real music.
March 2nd, 2009 at 2:48 am
I kind of agree with you that something like Photoshop is very difficult to make accessbile because it’s visual.
So it may be the case that Cappuccino and/ or Atlas are similar (I’ve seen neither, and I’m a PC user). My concern is about the accessibility of the apps that are generated by Atlas. Is there an example output of Atlas that we can look at?
March 2nd, 2009 at 10:30 am
Bryce, Ross, you should check out blind photographer Tim O’Brien who uses image manipulation software despite severe vision impairment.
Ironically, I’d imagine a desktop app like Photoshop would be, in theory, more accessible than a Javascript which emulates that in a browser. That’s only because I imagine the native UI widgets will tie directly to the OS’s accessibility features, whereas you generally have to hack that sort of interaction from javascript. It would be nice if a widget instantiated as an object in Javascript (eg. a tree control) could announce its role/state info to the OS in the same way. Then the canvas element (or whatever) would just be one possible rendering of something that’s richly described in the Javascript itself. Audio could be then just another possible rendering channel.
March 2nd, 2009 at 10:39 am
@Ben Darlow: Funk Rock is obviously the only kind of music.
@bruce: I’m not claiming accessibility is impossible, just not always obvious. I think Atlas has little impact on whether or not your Cappuccino application can be made accessible, though perhaps we can explore ways to make it help the process.
@Richard: You’re not making any sense. First, there’s no connection between the accessibility of Atlas and the accessibility of anything it creates. Second, nobody claimed blindness was the only problem, only that it presented a case where problems may not be possible to overcome.
As for your attack on Cappuccino, I suggest you take a look at any open source project ever. Open source is not about people choosing to solve the worlds problems and devoting their lives to it (except perhaps Richard Stallman). It’s about people solving their own problems, and believing that solution may be useful to others. We could have kept Cappuccino closed source, it would still be tremendously useful to us, but we wanted to share because we knew other people would fine it useful.
We never claimed it was perfect, hell it isn’t even a 1.0 product. And we’ve never claimed it was accessible, for many reasons, not the least of which is that it wasn’t even possible to make it accessible when we started building it.
The honest answer is, of course I could be wrong about this and other things. I am not an accessibility expert, which I’ve made clear. But that’s precisely why people knowledgeable about accessibility need to make an effort to become involved in projects and help educate about and even implement accessibility. Otherwise, you’re not going to get anywhere by just complaining.
Also, it surprises me how much attention people put on Cappuccino for this problem, when you consider that things like the iPod, having been around for more than five years, are still not accessible. The iPhone, which is revolutionary and cool, is completely inaccessible. Should Apple not make the iPhone and the iPod?
March 2nd, 2009 at 10:43 am
@Jim That’s a fascinating read, thanks for sharing. And what you’re describing is exactly the kind of API I wish we had for accessibility, instead of what ARIA actually offers.
March 2nd, 2009 at 11:25 am
It makes fine sense in my view. I appreciate you are humble to this, but I would suppose my main issue is that you come across as too lazy to learn accessibility, so figure that someone else will solve it for you.
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.
March 2nd, 2009 at 11:35 am
Richard, to claim that this problem has been discussed for the last seven years is to claim the Cappuccino is no different than other web apps out there. People haven’t even been building web apps for seven years, at least not in the sense that I mean the term.
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?
March 2nd, 2009 at 12:37 pm
Should Apple not make the iPhone and the iPod?
No, they should not! Wait…
March 2nd, 2009 at 12:40 pm
I know we’re playing with semantics here, but people have been building web apps as complex as Atlas, but in different forms, for as long as server side scripting existed. The minute JavaScript was usable people were using that too. Sure, it wasn’t as pretty and you didn’t get web too point oh! slidy things, but it was essentially the same concept. And people made the same mistakes that are being made now, and should not be being made so long after! And some were even accessible back then…
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…
March 2nd, 2009 at 1:06 pm
@Jim, thanks for the plug. We have a vibrant community of blind photographers on flickr @ http://www.flickr.com/groups/blind_photographers/. We are building new website around our group at http://www.blindphotographers.org which should go live in the next few days.
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.
March 2nd, 2009 at 1:32 pm
I think the point Richard is making can be boiled down to some key parts:
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.
March 2nd, 2009 at 1:45 pm
^ agrees with Bradley.
March 2nd, 2009 at 5:27 pm
Ross, I thought a bit more about my idea and realised what I’m describing is basically Java/Swing in Javascript. Are we saying that javascript should be extended from a language designed for DOM manipulation to one that can handle fully-fledged application programming? Because then we might be re-inventing the idea of applets. I’m not sure.
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.
March 6th, 2009 at 2:05 pm
@Richard: that’s good that you are off your soap box now. Don’t come back until you get what you are talking about.
March 11th, 2009 at 3:46 am
@Richard I think Ross has explained himself with clarity and decorum throughout this post. Rather that moan and criticise, be part of the solution, first by actually listening to what he is saying and secondly by offering to help. Accessibility on the web isn’t going to improve through flaming a well written, well thought out blog post.