The Intermission

I mentioned Adobe Thermo in an earlier post, but I recently found some more information that I thought was worth sharing. Peter Elst was able to snag a video of the Thermo demo at Adobe MAX in Chicago earlier this month. It’s just as awesome as you would hope!

If, as a designer, you’ve ever looked at a mockup you created and said to yourself, “I wish there was an easy way to make this just work” then Adobe Thermo is for you. After seeing how you wire together the parts of a mockup, it looks to be about as easy as you can make it. Well, it’s as easy as I can imagine it, which I think is saying something.

As Edna Mode from The Incredibles would say, “Words are useless, darling! Gobble gobble gobble gobble! There’s too much of it, darling, too much!”

[youtube ELM7rPiQyQY]

So I recommend you just watch the demo here. Be forewarned, the picture is really grainy. But if you’re interested in the next generation of rich internet applications, it’s a must see!

My only lingering question is about the fact that Thermo builds Flex applications, and I’m not sure how I feel about Flex. First, it’s an essentially proprietary format, like a Flash application. Even though Adobe has gone to great lengths to make Flex open-ish (e.g. announcing plans to make the Flex SDK open source), I would still prefer to build something that doesn’t require a special plugin. That’s strike one. Second, I’m not sure how accessible Flex applications are. Right now, the Flash plugin isn’t very friendly with screen readers and other assistive technology. That’s a potential strike two.

But, on the other hand, even if both of those turn out to be real problems, Thermo would still be a useful tool for communicating designs internally and to clients. Also, Flex is tied to another Adobe technology called Air, which promises to make Flex web applications into desktop applications that can run on Mac and Windows. So even if I can’t feel good about building Flex applications for the Web, it might still be a good option for desktop applications.

Bottom line: Keep an eye on this technology. I’m hoping it turns out to be great.

This past week, my company has been promoting web accessibility through a series of seminars that explain its importance for business and some techniques that we can use to make our web sites more accessible. On Friday, I attended a seminar hosted by the Cincinnati Association for the Blind and Visually Impaired (CABVI), in which they demonstrated how web sites appear to users with poor or no vision.

For those with poor vision…

For users with poor vision, they have applications that can zoom in so close that the icon for one application basically takes up the entire screen. These users work more slowly, since they have to pan around the screen a lot, but they can still use most web sites. Mainly, you just want to provide ALT tags for your pictures, since it’s hard to tell what something is at that close range.

For those who are blind…

For users who are blind, they have applications such as JAWS or Window Eyes, which read the screen for you. This is a totally crappy experience on the web. Really, I can’t exaggerate how bad it was. They guy who demonstrated these tools is an instructor at CABVI, and he seemed about as savvy as you can get with the software — and it was still awful. The software provides a lot of keyboard shortcuts, such as a key to move down to the next heading in the text, or a key to open a list of all the hyperlinks on the page. These keys helped a little bit, but you still have no sense of context for what you’re hearing. The screen reader tells you the name of a link, but you don’t know if you’re in the main nav, somewhere in the body (left column, right column, a call out), or in the footer.

Filling out a form is next to impossible. Screen readers operate by reading the HTML behind the page, not the page you would normally see.  So when the user tabs to a field, it often just says “edit field” without providing the name of the field. Who knows if it wants your name or your phone number or what. Unless the name of the field is directly before the field itself in the HTML, the screen reader doesn’t give you any context. (And although it seems like it would be easy to write HTML with the name of a field next to the field itself, it’s not. A lot of forms are built with ASP.NET or JSP, and it seems like those languages sometimes separate HTML and forms automatically.)

What can be done about it? - Part 1

In the meeting, my friend Ian asked if the people at CABVI have ever heard of Quicksilver. For those who don’t know, Quicksilver is an amazing program for the Mac. It’s like Spotlight, except much much cooler. You can find any file (let’s say a song) and do almost anything with it (e.g. open it with any application, play it in iTunes, show it in Finder, etc.) all with keystrokes. I think this would be especially cool for the blind because it’s very intelligent. For example, you could type “ffox” to find Firefox. The first time you do that, Firefox might not be the first result, but then next time you type “ffox”, Quicksilver is smart enough to know that “ffox” means “Firefox” to you. The developer, Nicholas Jitkoff, explains the theory behind his application in a Google video (warning: Nicholas is brilliant and worth listening to, but he’s not the most engaging speaker). In fact, his philosophy was a partial inspiration for my Google Social application.

So Quicksilver might be a good solution for the visually impaired on the Mac desktop (has anyone tried this before? can anyone confirm it?), but it doesn’t help too much for browsing web sites.

What can be done about it? - Part 2

My initial impression is that the people who develop screen readers are going to be constantly at odds with the legions of people who make web sites. Web developers are always finding new ways to do things, and web designers are interested in whatever technology helps websites look better (even though those advances generally seem to hurt accessibility), but almost nobody is thinking about accessibility. So these people developing screen readers are working as hard as they can to keep up with technologies that weren’t build with them in mind.

That reminded me of an important idea (that nobody talks about anymore) called the Semantic Web. According to the guy who invented the current world wide web, this is the future of the internet. Basically, it’s a new form of markup that allows machines to really understand what’s on the web.

Imagine, if we has semantically accessible web sites, your computer would know if a link is part of the main nav or part of the body. It would know the name of every form field. The computer would know what’s inside a picture. In the short term, this means your screen reader could actually be useful. In the long run, it means you could give your computer a command like “order me a medium pepperoni pizza from Pizza Hut” and it would do everything for you (like the Star Trek computer!)

Bottom Line

Those of us who are shaping the direction of the web need to support accessibility. My feeling is that making the web more accessible for the disabled will ultimately make it more accessible for everyone.