Interview to Aaron M. Leventhal
Aaron M Leventhal is the leader of Mozilla Accessibility Project. In this interview we covered the situation of accessibility, the troubles and the future of Mozilla's projects.
Hi Aaron, you are the key man of accessibility in Mozilla project, which is your experience in it?
I started working on Mozilla accessibility for Netscape in early 2001. At the time there was no accessibility architecture at all. Keyboard navigation was mostly unplanned, and the tab navigation system had big issues. We've cleaned all of that up. I've had to touch code all over the map in Mozilla, because accessibility bugs can happen almost anywhere. The accessibility project underwent a year-long pause when AOL cut the Netscape browser division. Since then, IBM has picked the project up because they realized how important it was. They hired me as a web accessibility architect. My first job is to ensure that Mozilla accessibility becomes a reality. We've come a long way and expect to start attracting a larger community of users with disabilities in the coming year.
In a recent interview, you showed up your deep knowledge in current accessibility problems. Before talking about relations with alternative tools and Mozilla projects, which is your impression about assistive technologies?
The assistive technology industry sells expensive products, relative to what mainstream users are accustomed to. For example, a typical solution for a blind computer user would cost between $2000-$10000 extra beyond the cost of their PC for a screen reader, book reading software and optionally a Braille display. The screen reader is the most essential piece, and costs about $1000. The quality of both the software and hardware is typically pretty good, and the cost is actually justified because the vendors have to work very hard to remain viable in a small market. These are not easy products to develop.
Unfortunately, many of today's solutions work with very few software packages -- typically the most popular package in a group of similar packages. This means users have relatively few choices. Why? It is just too expensive to make truly accessible applications, both for the application developers and the AT community.
The good news is that those end users who can afford the adaptive software and equipment, or have it paid for, can often find a pretty good solution for many of their needs. The user community appears to have grown accustomed to imperfection and long waits before new technologies become accessible. Expectations have become more realistic in many cases. However, I don't think this is as good as we should expect things to be. Many individuals still go without the technological solutions they need, and many important software packages and website are still not usable for a lot of people.
On the other hand, the long term dream of accessibility everywhere simply isn't going to happen without huge changes in the industry. It's not just about having enough money to drive accessible design. The design knowledge and developer skills need to be taught in universities and technical schools, which means computer science and design professors need to learn about it too! Accessibility needs to become a truely important part of our development tools and technical culture. In general, people in our industry need to care more about the variety of user types out there, such as old and young people. This is the idea behind universal design. The best way to understand accessibility is to realize there is no great formula or definiton that will make you do it well. True understanding only comes by taking some time and sitting down with a variety of different types of users and watching them work.
Often, assistive technologies are not so W3C consistent. In this way also the correct webdesign is difficult. What about?
In my opinion, the root of the problem is that the academic people who write standards and the pragmatic people who write assistive technology software have different approaches to accessibility. Both approaches have their strengths and weaknesses. People who write standards are often attracted to the challenging problems related to finding an elegant answer that covers all cases, such as model-view-controller architectures, or separation of structure from presentation. The standards writers want their standards to be relevant for as long as possible, in as many ways as possible. They want to avoid being tied down by specific technologies such as HTML, keyboard input or GUI accessibility APIs. The standards should look ahead to the future and provide important insights and ideas for "legacy technologies". However, the abstractions that result may ignore mundane problems that every day users and developers care about, which happen to cause the majority of work.
People who write software want to cover the most important cases that their paying customers see. They have too much work to do, and don't have time for something unless there is a business case for working on it. When developers read standards documents, they may have a hard time gleaning useful work items from them for a variety of reasons. Besides being difficult to understand, the documents may be simply rewording most of what these software developers already know, yet ignoring a number of real problems like interoperability. Basically the software developer just has time for a practical list of potential defects and proposed user models. The downside of the developer approach is that somteimes crucial higher level rethinking doesn't happen. Short term bandages are applied which fix problems to specific versions of specific applications. If a problem is perceived as rare it will probably never be addressed, even though it may be very important for a handful of users.
In the end, we have the situations like the one you have stated -- a gap between W3C's accessibility specs and the reality of implementations. The best solution is a set of practical guideline documents to fill this gap. For example, web developers may appreciate IBM Web Accessibility Checklist (which I was using even before I joined IBM) and the IBM Java Accessibility Checklist. They are both very readable and implementable. If you follow these documents, your users will enjoy very good accessibility. Legal compliance is something else entirely -- developers need to keep that in mind. In fact, the EU is looking to use the W3C's WCAG 2.0 as a basis for some web accessibility requirements.
Another thing that would help developers is more documentation and resources from the assistive technology vendors themselves. It would even be helpful to have Bugzilla or other issue tracking web applications used for collaborating with developers.
I see the Firefox 2.0 roadmap. One goal is the accessibility compliance. What does it mean exactly, which are the improvements you expect to do?
Compliance can inidcate a variety of things. W3C UAAG compliance is not our first goal for Mozilla accessibility. Our first goal is Section 508 complicance. Section 508 is a U.S. government regulation that provides 12 requirements for desktop software before it is generally acceptable to be used in government offices. Here's a rough, non-legally binding document describing how well the classic Mozilla suite's browser is doing in terms of Section 508 compliance.
There are two main areas of Firefox accessibility. The first part is the HTML window, which will be the same as what we have in the classic Mozilla suite. This area is in pretty good shape, although we have a DHTML accessibility project, and will also want to make XForms accessible.
The other area is Firefox's user interface, which is different from the classic Mozilla suite's. One of the reasons that the Firefox UI is so great is that a very small group of developers worked very closely on it, and only started allowing the larger community of developers access to it after much progress was made. Unfortunately, accessibility was not always considered during these early stages. As a result, we have a large number of small scale glitches that need to be fixed. The most common problem is missing keyboard functionality, such as the innability to compeltely use the options dialog with the keyboard. The other major set of problems is widgets that are not correctly exposed, such as the download manager, which screen readers currently can't recongize as an interactive list of items. In general Firefox is like a rough sculpture which needs to be polished for accessibility. The basic structure is already there, but the details are very important.
XUL and accessibility. At now, which is the best platform to develop accessible application in Mozilla suite: web based or XUL based? Why?
I don't like my own answer, but at the moment, the truth is that web-based is better because your customers can always fall back on Internet Explorer if there is a accessibility problem in Mozilla. With XUL, Mozilla is the only application that will run it. Because accessibility is still new in Mozilla, you cannot count on users having a complete accessible solution based in it. Keep in mind there is no truly widely used accessibility community on anything but Windows. This will most likely all change over the next couple of years. It is normal for new environments to become fully accessible fairly slowly.
IBM is deeply involved in Mozilla projects and accessibility. Some cool news for the future?
For me, the coolest project is DHTML accessibility. Up until now, DHTML has not been a real option for developers who care about accessibility. IBM is working to change that, so that developers can create custom DHTML widgets and have them be accessible with the keyboard and assistive technologies. Developers can already do the first part, keyboard accessibility. I'm working on documentation for it, Key-navigable custom DHTML widgets, in Mozilla & IE. With web applications such as Gmail becoming more popular, this is an important area that needs to be addressed. The second part of dynamic content accessibility is going to be the use of additional HTML attributes to describe the role and state of custom widgets. For example, it will be possible to describe a <div> as a tree item that is expanded.
Beyond that, IBM is working on XForms and SVG implementations for Mozilla, which will be great for developers who can use XHTML. I'll leave it to our P.R. department to send out press releases on other projects, which will end up in the industry press.
What about XHTML? Do you think it could be the panacea of accessible-cool-killer-webdesign?
XHTML 2 isn't on anyone's radar for Mozilla, as far as I'm aware. For XHTML 1.x, there are a lot of problems. As long as IE doesn't render true XHTML and make use of namespaces, developers will have to serve XHTML pages with a different mime type in IE vs. Mozilla (http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html). The real point of XHTML is that we can have content from other namespaces such as XForms and SVG. Since those won't be available in IE, the whole concept is not nearly as valuable. I don't think we'll be able to call any XHTML solution a panacea for a long time. Even if Firefox does very well, I find it unlikely that Microsoft will release a highly standards compliant browser which supports technologies that reduce lockin to Windows technologies. I also don't envision IE becoming irrelevant. However, work to progress the web to a better design needs to continue and will one day be worth the effort.
Thanks for you patience and time, now a free thought from you!
I'm honored to be interviewed by your magazine, and am always happy to find others interested in accessibility. I'd like to invite your readers to send Mozilla accessibility related questions to my email, aaronleventhal@moonset.net
Thanks Aaron, I really appreciate your availability and kindness.
Thanks again for the interview!