aaron cannon archives

case study

The Accessibility Checklist
I Vowed I’d Never Write

Update: The below checklist is now available in German.

I have said on numerous occasions that there is no simple checklist that, when followed, will give you an accessible site without fail. There are simply too many variables. But, what do you do when you want to create accessible pages and you have dozens or even hundreds of developers who (like most of their peers) have little to no experience with accessibility? What do you do when it just simply isn’t practical to have someone review all of your pages? In short, how do you insure that a very large organization creates pages that can be accessed by the largest audience possible without drastically increasing your budget? This is one of the questions we have been (and continue to) struggle with.

posted by cannona on Friday, Jun 06, 2008 · 6 comments

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

Did you know if you link images with out paying a license fee, you are violating a patent? Tis true. I wonder how many companies they’ll sucker into paying them.

posted by cannona on Thursday, May 29, 2008

I love to read. Some books I want to keep, but others I only need to read once and then I’m done. Until recently, my books just piled up. But then I discovered a free web site that helps me manage my book piles. PaperBackSwap.com is a site that facilitates the swapping of books (both print and audio) with other people who also read way too much. A very cool site.

In the interest of full disclosure, if you use the above link to sign up, I get credit.

posted by cannona on Tuesday, May 13, 2008

Aaron Barker sent me a great article on ARIA and how it can be used to make AJAX apps more accessible. I expect that as the standard evolves, it will do great things for improving the accessibility of the richer web applications.

posted by cannona on Tuesday, Apr 29, 2008

Ars Technica posted an interesting article on the gaming industry and how they have all but forgotten colorblind gamers. Not surprisingly, folks who are colorblind manage to play anyway. In fact, I my self used to play Mike Tyson’s Punch-Out!!. (I could get all the way up to Bald Bull.) Apparently, based on my conversations with other totally blind people, this is not as unusual as you might imagine. There have always been video games which (probably unintentionally) gave the user enough information to literally play blind.

posted by cannona on Thursday, Apr 10, 2008

Kids annoying you? Finally, a real solution.

posted by cannona on Friday, Apr 04, 2008

posted by cannona on Tuesday, Apr 01, 2008

posted by cannona on Monday, Mar 31, 2008

posted by cannona on Tuesday, Mar 11, 2008

What lengths would you go to to access the internet if your government restricted its access? Here’s an article on what some Cubans are doing.

posted by cannona on Friday, Mar 07, 2008

“Look, we all have something to bring to this discussion. But I think from now on the thing you should bring is silence.”
Arnold Rimmer – Red Dwarf

posted by cannona on Wednesday, Feb 27, 2008

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

Interestingly enough, the IHam site is surprisingly accessible with Jaws, in spite of the fact that its almost entirely flash. That certainly bodes well for the accessibility of the IHam product.

posted by cannona on Tuesday, Feb 05, 2008

Ran across a great article on WebAIM titled CSS in Action: Invisible Content Just for Screen Reader Users. It discusses several techniques for “hiding” content so it is only available to screen reader users. The article covers hiding form labels, skip navigation links, and other content just for screen reader users.

posted by cannona on Thursday, Jan 03, 2008

Christopher Philips sent me a link to a very interesting article on accessibility as it relates to large organizations.

posted by cannona on Wednesday, Dec 26, 2007

Can Google make a better Wikipedia? We might get to find out, acording to an article on Ars Technica. It looks like a good idea, but I don’t really think it will effect Wikipedia much, even if it does become popular. The reason is that the two sites don’t seem like they would be in direct competition as they provide two very different services, with each offering something the other does not. They might steal some traffic from one another, because if someone finds the information they are seeking on one site, they might not visit the other, but that can be said about just about every site on the web.

posted by cannona on Friday, Dec 14, 2007

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:

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

Two great finds today! The first is this video from Victor Tsaran at Yahoo. He gives a very in depth demonstration of how a blind person uses a screen reader, like the kind I wish I could have done during my presentation if I had had more time.

The other find is a study which is nearly five years old, but still gives some great advice which is as relevant as ever. Basically it’s a government sponsored study which tries to answer the question “what helps and what hinders screen reader users?”

posted by cannona on Friday, Dec 07, 2007