Today I sat in on the the “Assistive Technology Access to Flash and PDF” session presented by Matt May from Adobe Systems.

There it was announced that the next release of Acrobat, Acrobat Reader, Flash Player and Flex will support the iAccessible2 API. MSAA is what these products currently use which limits the accessible API to Windows platforms. This is great news as this will expand accessibility for these products beyond the Windows platform and allow users of OS2 and Linux to make use of the accessibility features in these products.

If you are not sure what iAccessible2 is, Peter Korn’s Weblog has a great explanation at: http://blogs.sun.com/korn/entry/completing_the_accessibility_picture_iaccessible2.

In addition to the support of iAccessible2, Adobe is planning on including support for the ARIA specifications in the near future for Flash Player and Flex. This will make it easier for developers to expose Flash content to assistive technologies.

It sure is nice to see advancements like this being made in these products. The hope is that the industry as a whole will follow Adobe’s example!

If you happen to be at this conference, feel free to stop by the HiSoftware booth #108 and say ‘hello’ as that is where I’ll be hanging out!

I’m sure most everyone that has used an ATM can identify the braille on the buttons of the machine, but what about all text and questions that appear on the screen…none of which are accessible?  As the US continues to play catchup in the world of electronic accessibility even countries such as the Philippines are making efforts… http://businessmirror.com.ph/home/banking-a-finance/15664-bill-pushes-accessibility-of-atms-to-the-blind.html

I first became aware of the new version of this editor from the following news article: FCKEditor drops the F. This article mentioned that the editor was now ‘fully’ accessible to screen readers and keyboard only users. Even the main page for the CKeditor website (http://ckeditor.com/) makes the claim that it has full accessibility support.

This editor is open source and versatile when it comes to implementation so it is has a large install base. You may have used this editor yourself without even knowing it. With the growing attention to accessibility and the legal requirements around this topic an updated ‘accessible’ version of this editor is very timely.

I have done some testing in the past with the FCKEditor in regards to accessibility and was curious if this new version was really accessible. So I took a ‘quick’ peek to see for myself. My focus for this quick test was not if the editor created accessible content, but on if the editor itself was accessible.

Keyboard Only

I was pleasantly surprised to find that the CKEditor does in fact support the use of only a keyboard! Many of the past keyboard problems with the FCKEditor have been fix. I honestly did not expect the level of keyboard support that I found in the new version of this editor.

To say the least I was very pleased! The one drawback was finding the reference to the keyboard only commands. It wasn’t that hard to find but did take me a few minutes. What would be nice is to have a link or easily discoverable way to allow a user to get this information from within the editor itself.

You can find the reference for the most common supported keyboard commands and navigation shortcuts in the CKEditor Accessibility topics document.

Screen Reader

When it came to using a screen reader like JAWS with the CKEditor I was sure I would discover some major issues. Again, to my surprise JAWS and the CKEditor worked fairly well together. There is still a steep learning curve and at times JAWS got lost which required some screen refreshing and rediscovering of current focus to get my bearings. Compared to the way JAWS and the FCKEditor worked (or should I say did not work) together in the past this was a tremendous improvement.

To CKEditor’s credit most issues of using JAWS with this product are documented. This was in the CKEditor’s Accessibility document mentioned early or if you prefer jump directly to the JAWS section of that document here.

In case you are interested I used IE 7.0.6001.18000 and JAWS 10.0.1142 for my testing.

In Summary

There are still some areas that are problematic such as switching from WYSIWYG view to the Source view. When this switch occurs the focus jumps from the editor to the top of the page. This is not good for a screen reader user, screen magnifier user or a keyboard only user.

Also, I was not able to find a complete list of keyboard commands for ALL available tool bar options. It could be that those have been deprecated. The FCKEditor had a much larger list than that outlined in the current CKEditor Accessibility Document.

In all fairness I did not do an exhaustive search but I still feel a reference like that, if still applicable,   should be easily discoverable and even be referenced within the CKEditor Accessibility Document.

I should also mention that I did not do a complete test of the editor for accessibility but took a high level approach. Even so, that high level approach shows that the creators of CKEditor have put great effort in making this an accessible product.

This is very commendable because all too often the minimal effort is done so a product can be called accessible. I am not saying that the CKEditor does not have accessibility issues but compared to the previous versions of the FCKEditor the difference is night and day! This was a *real* effort to create an accessible product and so I offer a hearty ‘WOOT!’ to the CKEditor team!

If you have had a similar or different experience with the new CKEditor please post your comment here.

Flash accessibility is a common issue we come across.  Many people think that Section 508 and WCAG standards mean you cannot create a dynamic website…this I’m sorry is simply not true.  There is however a different learning curve needed to make Flash content accessible.  Here is a great post I found that discusses the accessibility/usability and some best practices for using Flash content… http://sixrevisions.com/usabilityaccessibility/adobe-flash-accessibility-best-practices-for-design/

This instance took place within New York State, but this precedence should spread much farther than the state line.  As corporations continue to ignore the need to make things accessible they will continue to open themselves up to possible lawsuits.

This also brings up an interesting point that often gets overlooked as many of these same laws apply internally at a company as well.  Making your products and services accessible to customers isn’t where accessibility should start or stop.  Any corporation potentially runs across the same issues when an employee has the same problem.  Think about how many computer programs you use at work everyday and chances are 99% of them are not accessible.  It’s not necessarily harder to make things accessible but it does require different knowledge.

For a company that announced $634 million in quarterly earnings earlier this month, $6 million might seem like “nuisance value” to make this suit go away.  I don’t think so for four reasons.  First, Target fiercely fought this case and dragged it out– so why stop now?  Second, the court’s previous rulings got the law right and things weren’t looking great for Target.  So, settling now avoids a lot of trouble down the road.  Third, the $6 million only goes to class members in California (Californians get the lucky break because, while the case was brought under the Federal ADA statute and the California state law, only California law authorizes the court to award money damages– yes, what state you live in really does affect your rights).  The settlement authorizes $3,500 for each valid claim (up to two per person), which isn’t bad compensation for not being able to buy a $1.99 bottle of detergent online from Target.com on a given day.  Fourth, Target is under some pressure right now to make sure it doesn’t waste money.  While it’s hard to feel sorry for a company that just earned $634 million this quarter, those earnings actually represent an 8% loss in revenue.  If they don’t shape up soon and tighten their belts, there are going to be some pretty angry shareholders out there.

I’ll spend some time describing the case in more detail in a later posting (far too much for 11:00 pm) but a few thoughts occur to me.  First and foremost, from a legal perspective, we can’t get too excited about the settlement because it’s only a settlement– without a court actually saying websites have to be accessible, no one is yet compelled to make them accessible (this is no slight against NFB’s attorneys or the strength of their case– a lawyer is ethically obliged to recommend a fair settlement offer to their client).  But second, from a business perspective, major companies do have reason to be concerned for two reasons.  With NFB’s success, other advocates may sense blood in the water and this may increase the chances of getting hit with a suit.  Additionally, most major companies have a large customer base in California and they can’t just say, “we sell to anyone but people in California.”  If you can’t wait until then, you can always check out the settlement yourself at http://www.nfbtargetlawsuit.com/.

Of course, in our legal system, anyone can sue anyone for anything.  This is annoying for anyone, particularly because defending a suit is expensive.  But there are some things that companies can do to minimize their risk of getting sued in the first place.  I’ll explore some of those strategies in a later post, but the most obvious one is “don’t be a target” (pun intended).