Google Docs will never become a dominant word processor unless…

You guessed it, they make their interface accessible. If you are not able to use a mouse or see the screen, you are basically out of luck when it comes to Google Docs. The best you can do is read what others have wrote, and even that is a bit awkward.

Granted, it will not be easy for Google to substantially alter this situation with current popular techniques, but it should be made a lot simpler with the Accessible Rich Internet Applications (WAI-ARIA) standard being worked on by the The World Wide Web Consortium.

For those who are not aware, ARIA is a proposed standard which, among other things, seeks to bridge the gap in communication between the screen reader and dynamic web applications. It allows you to tell a screenreader user, for example, that a particular element on the page is a drop-down menu, add enhanced keyboard functionality, and draw the users attention to elements that change. It is a very promising standard which is already seeing some support in the latest versions of screen readers, and a few of the very recently released browsers.

But getting back to Google, I believe that inaccessibility will very likely hold them back in the market. It is true that the vast majority of users don’t even know what accessibility is, and if they do, they probably don’t pay it much attention. So how could it substantially effect them in the market? There seems to be a growing trend within a few companies, but more within government, to discourage the usage of inaccessible products when accessible alternatives exist. I believe that at least some of the efforts being put forth by companies to make their products more accessible can be directly attributed to these regulations and policies. Of course, I don’t wish to imply that it’s entirely a business decision, as I am sure many companies do it because they care. However, having a little market pressure never hurts.

Right now, Microsoft Office works great with any screenreader worth speaking of, and if you’re the person responsible for deciding what software your organization will use and you have a mandate to consider accessibility in your decision, MS Office has a big advantage that might be difficult to overcome.

Nevertheless, because of the afore mentioned market pressure, and because of Google’s promising history of making virtually all of their other web applications accessible, I am quite optimistic that I too will soon have the opportunity to use Google Docs.

posted by cannona on Friday, May 30, 2008 · 0 comments

Adobe Flex is Accessible? Show me.

My recent post on the accessibility of Adobe Flex prompted a response from Adam Lehman, an employee of Adobe. His blog post humorously titled “Is Adobe Flex Really Accessible? You bet your robot voice it is!” talks about a few aspects of Adobe Flex which he claims makes it more accessible than the alternatives. Unfortunately, the issues raised in my original post remain, for the most part, unaddressed.

Adam says on his blog:

I think where Aaron had a rough time is that most of the accessibility information on Adobe.com for Flex needs to be updated. It looks like all of the information is based off of Flex 1.5. It’s definitely something that needs to be addressed and our accessibility team is working on it. I’m also willing to bet that all the applications Aaron tested weren’t the best examples of applications designed to be accessible.

I would point out that the applications I tested were those on the above mentioned site that were specifically recommended by Adobe as examples of accessible apps. It is not clear from Adam’s post whether or not those applications are also in need of being updated. It is also not clear if the Jaws scripts (which, as you will recall, I could not get to install on either of two machines) are also slated for update, as they were not mentioned at all.

It is great that Adobe seems to be actively working towards making Adobe Flex accessible. However, “working on it”, and actually being accessible are two very different things.

Again, if I am wrong, I would love to know about it, and I will of course update this blog with any new information. However, at this point, without having actually experienced an accessible Adobe Flex application, I can not recommend it as an accessible solution, though I do hope that that will change.

Sorry for the lack of comments. I’ll keep bugging the admins and hopefully we’ll have them soon. In the meantime, please feel free to email me at [email protected] (removing all of the hopefully spam-bot foiling q’s.)

posted by cannona on Friday, Feb 08, 2008 · 3 comments

Is Adobe Flex Really Accessible?

Short answer: no, at least not as far as I can tell.

When I first heard that Adobe Flex was accessible, I was naturally quite excited. I had heard about how powerful the technology was for building rich web apps, and I couldn’t wait to try it. Unfortunately, I didn’t get around to taking a closer look until recently, when I was asked to conduct an evaluation by some folks at work.

Adobe has some sample Flex applications available which supposedly show off there accessibility. Unfortunately, they didn’t seem to work that well for me with Jaws 9.0. Almost none of the controls were readable.

Digging around a little more on the adobe site brought me to their page on using Adobe Flex with Jaws where I read:

In order to most effectively use the JAWS screen reader with an Adobe Flex application, users must download and install scripts. These scripts enable some of the accessibility features of Flex and allow users to utilize the standard JAWS keyboard shortcut to enter Forms mode on a larger set of user interface controls than would otherwise be possible. It is important to direct users with visual impairments to this page so that they will have the necessary scripts to use JAWS effectively.

A little background may be in order at this point for those who are less familiar with Jaws for Windows. Jaws is a very powerful screen reading program, and part of its power comes from the ability to use custom scripts. Unfortunately, many users have never installed Jaws scripts, and may not even realize that it is an option.

So, undaunted, I downloaded the Jaws script files to try the demo again. Just one problem. The scripts would not install. I tried on two different computers with a few different versions of Jaws with no luck, and it appears I am not the only one to encounter this problem.

I find this situation to be quite disappointing, as Adobe has done a lot for accessibility in the past. However, as it stands now, the claim that Adobe Flex is accessible seems to be nothing more than marketing hype.

Hopefully, Adobe will put some more time into making Flex truly accessible. It would also be nice if they could get Freedom Scientific (the company which owns and maintains Jaws for Windows) to bundle the scripts with the program as has been done for many other applications. However, until that happens, I can not recommend Adobe Flex.

I would love to be proven wrong, so if you know of a way I can get this to work, please email me at [email protected] (removing all of the hopefully spam-bot foiling q’s.)

Update: This post sparked a response from an employee of Adobe. See this post for further details.

posted by cannona on Wednesday, Feb 06, 2008 · 0 comments

In order to keep out spammers and blind people, please type the characters you see below.

If you’ve been online longer than a day or two, you’ve undoubtedly been confronted with a CAPTCHA: one of those annoying collections of numbers and letters that you have to type into a form before you can continue. A lot of complaints have been made about their inaccessibility, but what are the alternatives? Even more importantly, when are captchas necessary, and when are they overkill?

Before trying to answer the above questions, I would like to define captcha. In short, the definition of a true captcha is a test which can be designed by a computer, but only answered by a human. In addition, each test should be unique with a high degree of probability. If you think about it, this is actually a very difficult problem, and its only going to get more difficult as computer speeds increase and the computer sciences advance. In fact, many captcha schemes currently in use have been broken, although the processing time often makes this impractical for attackers. But again, as time goes on, this will be less of an issue.

When deciding whether a captcha is warranted, at least three factors need to be considered:

1. Is your site high traffic or a high value target?
2. If an attacker gained access, could they cause a serious problem for you or your users?
3. Are there other less intrusive ways to keep out attackers?

If the answer to 1 is no, you should consider the fact that it is probably easier for an attacker to just spam you manually rather than write a script to do so. If 2 is no, then why burden your users needlessly? If 3 is no, then again, think of your users and find an alternative.

If your site is small, you might try a weaker type of captcha which is accessible. For instance, you could create a list of simple questions and answers, and then present your users with a random one from the list. The problem with this is obvious; an attacker can just keep hitting your page until they’re reasonably certain that they’ve seen all of your questions, and then alter their spamming software accordingly. However, if your site is small enough, it probably won’t be worth the effort, and the attacker will either go some where else, or just answer the question manually (which is obviously something which no captcha can protect against, no matter how good).

But what if your site is a high value target, and you definitely need a captcha? There are still a few alternatives. You can setup a standard captcha for most users, and provide an email address or phone number (hopefully with TTY) that disabled users can use to verify that they are in fact a real person. This has the advantage of being accessible to practically everyone, while being hard for an attacker to automatically thwart. The drawbacks are that it would cost money and time to maintain, and, depending on how you had it setup, might require the user to wait for a call back or returned email. Unless the user can gain access in a timely manner, however, I would not consider that they are being given equal access. In addition, (if you provide a phone number) it may not be available to all users, such as those without the ability to make international or long distance calls.

The other option of which I am aware is to set up an audio captcha in addition to a standard visual one. The benefits are that, once it is setup, it would require almost no maintenance, and most disabled users wouldn’t have to wait for a return email. The disadvantages are that it is not accessible to deaf-blind users, and persons who can’t hear the file for what ever reason. It may also not be as secure as a traditional image captcha, although this undoubtedly depends greatly on the implementation.

So how do audio captchas work? Essentially, they work like visual captchas, except that instead of reading a series of numbers (and sometimes letters) you listen to them.

If you do a Google search for audio captcha, you will find a few pre-made solutions. Unfortunately, none that I have found are adequate. They provide a little security, but not much. One problem with all the ones I have seen is that they use synthesized speech to produce the captcha. However, synthesized speech is highly predictable, in addition to being a little hard to understand at times. This means that all an attacker has to do is find out how a computer says each letter, and then match those patterns in the captcha. The other closely related problem is that the program does not introduce any randomness into the captcha, aside from the selection of the characters. This is like having a visual captcha with no variation in how the letters are displayed; it would be very susceptible to analysis by optical character recognition software.

A very few audio captcha generators seek to introduce a little more variability into their captchas by randomizing the voice, pitch, and speed, but I contend that this is still not sufficient to increase the computing cost to the attacker by much. However, it probably does make the captcha more difficult to understand for the user.

So what is the solution? I believe the best and most secure option currently available is to create an audio captcha with human read characters. It must also have a lot of random noise added to it to make pattern recognition more difficult. A good audio captcha generator should do as many of the following as is feasible:

• string together the human read audio characters with randomly varying spaces between them (an exponential distribution works well for this).
• Randomly Vary slightly the speed, pitch, and/or length of each character (A Normal Distribution works well for this).
• If possible, each character should be read by the same person several times varying slightly the manner it is said, and the program should randomize which of the pronunciations it chooses to present to the user.
• Randomly generated noise should be added to the output.
• Random bits of speech from a person of the opposite gender of the reader should be mixed into the audio. (This helps because the human brain is good at distinguishing between different voices and tuning out those of no interest, though reversing the mixed-in speech can help minimize distraction.)
• Each PCM audio sample should be randomized slightly (A Normal Distribution with a low variance is good for this; too large a variance causes too much distortion and makes the speech unintelligible).
• Add random types of echo to the characters.
• Encode the audio into a proprietary format which is not easily converted.

As with visual captchas, care must be taken to insure that your security measures don’t effect the usability of the captcha. However, the above mentioned techniques should make it more difficult to automatically recognize your captcha text, though it is certainly not impossible. Nevertheless, Google, Microsoft, and other companies have been using many of the above techniques for several months; you can make your own conclusions.

I believe that captchas are currently one of the biggest barriers to accessibility. Unfortunately, there appear to be no perfect solutions. Even the last option is pretty secure, but its still probably not as good as the traditional image captcha. Further thought and research is definitely needed, so if you have any ideas, please don’t keep them to your self.

For further information and some history, see the Captcha article from Wikipedia.

posted by cannona on Friday, Dec 14, 2007 · 0 comments