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!

The Access Board has just released the draft of the refresh for the Section 508 standards. You can view them at this link: http://access-board.gov/sec508/refresh/draft-rule.htm

The guidance on this site seemed very detailed and in depth so I thought I would review it in case I could pick up something new.

The Problem

As I read through the site I came across a statement that said the style for Header 1 (that is heading level 1) should only be used once in a document and that it should be used as a title. I am not sure why this advice was being given because Word provides a style for the title of a document. The style is called, oddly enough, ‘Title’. In fact, using the ‘Header 1′ style for a title is going to cause problems with your table of contents, if you choose to use a TOC.

The site went on to describe how to remove the Header 1 style from the TOC outline. I thought to myself, “Hmmm. Why would they do that? Maybe they don’t like the way the Title style is formatted. If that is the case why don’t they just modify the style to look the way they want?”

As I continued to read it was mentioned that there is a bug with the TOC in Word 2003 and that a after the TOC is created in a document the user should cut and paste the TOC into Notepad. Then after that they should copy the TOC from Notepad and paste it back into the Word document. What?!

All the advice this site had given was pretty accurate so far. This business about using Heading 1 as a title was a bit odd but now this TOC stuff was just plain ridiculous. If I follow the advice on the TOC all I have done is negated the benefit of having a TOC in the document! For example the bookmark links were automatically generated are now gone. Any formatting that the TOC had is now gone. I also no longer have the ability to update the TOC should I make changes to my document. If I do make changes to the document I have to recreate the TOC, paste it into Notepad and then back into Word and manually reformat the entire TOC. Why would they give such crazy advice?

The “Ah-Ha!” Moment

Now at this moment I would usually just close my browser and say, “What is wrong with the people who created that site?” But something was nagging at me to look further into what they really were trying to accomplish. The site mentioned that this TOC workaround needed to be done because there was a bug in Word 2003 and the way it handled the table of contents. It also said that this issue had been fixed in Word 2007. The site didn’t go into detail about this mysterious issue that caused them give such nonsensical advice.

So I decided to break out my install of Office 2003 and poke around a little to see what I could figure out. As I tried different things I quickly discovered an issue with the TOC. Some of the heading levels were not showing up in the TOC! I tried the same steps in Office 2007 and found that this behavior was not happening in that version. Could this be the reason for the strange advice being given?

I am not sure if this is the reason, but it does tie the header and TOC advice together or at least places them both at the scene of the crime. I am going to assume this must be the apparent ‘bug’ that was referenced.

The Fix!

As I contemplated why the TOC in Word 2003 was not including all the headers in the document I discovered the reason by showing the formatting marks in the document. This is done using the Show/Hide command button while in the Normal (Print Layout in Word 2007), Web Layout or Draft Layout views.

To turn this feature on and off you select the button with the paragraph mark on it  or use the keyboard shortcut which is Alt+Shift+*. When it is on your document will include the various formatting marks demonstrated in this screen shot:

What I noticed is if a page break was used and there was no carriage return just before the break then the heading that followed on the next page would not show up in the TOC.

How could this happen? An example would be that you are typing in Print Layout view and you have inserted a page break. You notice that there appears to be an extra line below the last paragraph on the page. It looks this way because the cursor is sitting there flashing at you (this is due to the carriage return).

So you use the backspace key to remove that apparent extra empty line. When you do this you have effectively removed the carriage return. Now the paragraph and page break no longer have a carriage return to separate the two.

Here is an image of how the document would look with the the carriage return properly located between the end of the paragraph and the page break:

When the carriage return is removed this creates the situation as demonstrated in the image below:

That carriage return is essential if you want the header style at the top of the next page to be included in the TOC.

If you are a user of Word 2003 go give it a try and see for yourself! If you find that the header does not get added back to the TOC after you re-add the carriage return, then select the header text and reapply the style.

Summary

Now I am not sure if this is in fact the issue that was being discussed on the site I mentioned earlier. If it is or is not the fact is the advice that was given on that site is just plain bad advice.

By using the proper styles and other features in Word such, as the Table of Contents, correctly your document will be better structured as an accessible document. Then if you export your document to a PDF format that structure will be exported also which again provides better accessibility.

Now I don’t want to knock the effort that was put into creating the content on the site mentioned above because the majority of it was correct. I want to encourage more effort to share this type of knowledge. This way we can help to ensure that content is accessible to all users.

That being said, I also want to encourage that any advice that is given be as accurate as possible. If you run into issues like that demonstrated in this blog post please don’t just make things up. Take the time to do your own research and post comments and questions on blogs like this one. You may find someone who can provide you the solution.

Most importantly do not assume that everything you read online as correct. Do your due dillegence! As mentioned in the title of the post, when it comes to free accessibility advice…caveat emptor!

If you disagree with my comments, have run into similar situations or have any questions on accessibility issue s please post your comments and questions here.

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 isn’t the first time that New York has required Web accessibility — the first one I remember was the New York settlement agreement with Ramada.com and Priceline.com from way back in 2004. My big criticism of the 2004 Ramada.com and Priceline.com settlement agreements was that they required compliance to a random collection of requirements from the Section 508 standards and WCAG 1.0 level 1 and 2 guidelines.  Settling now on WCAG 2.0 Level AA is a huge step forward.

To my mind, there are three big take away messages from the settlement.

1. Meet WCAG 2.0 Level AA.  WCAG 2.0 is here to stay and Level AA compliance is the bar that everyone should be shooting for.  Level AA compliance is being required by more and more public governments throughout the world and it is nice to see a settlement agreement under ADA Title III that follows suit.  It’s a pretty tough standard to meet and could certainly be clearer, but at least it’s uniform requirement.
2. Don’t Forget About Target.  NFB v Target remains the biggest reason why private companies need to make their websites accessible.  California’s Unruh Act and Disabled Persons Act, together with the enforcement provisions that impose treble damages starting at $4,000 are powerful tools indeed.  Only works, however, for companies with customers in California.
3. Don’t count out the ADA.  The latest New York settlement agreement just adds further reason why companies might face an ADA lawsuit if they don’t take Web accessibility seriously.  Although the ADA doesn’t include monetary damages, no company likes the negative publicity that accompanies claims that they discriminate against people with disabilities.

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.

The fact that IE works is actually an old IE bug and some dumb luck.  You’ll notice in IE that if there is only a title attribute it will be read by JAWS, if there is a title attribute and alt-text the alt-text is read by JAWS.

2.  JAWS defaults to read alt and not Title attributes however this can be modified through the configuration manager…Set Options–>HTML Options–>Links–>Use Title; this will change your settings until you change them back which I don’t recommend but it is a good way to show that your code is working in this manner.

The real fix here would be to add alt-text which should be picked up by default with JAWS 10 in Firefox.

Just as another possibility you can do an about:config in Firefox and make sure browser.chrome.toolbar_tips is set to true or you won’t see the tool tips at all.

Long story short here is that we’ve all gotten so used to something not working right that we came to think of the behaviour as being correct.  Bad on us.

What often gets overlooked is the usability of the site. No matter how ‘compliant’ your site is it can still be unusable or at least not as easy to use as you may think. How so?

Let me give you an example. I was recently in a meeting with a client who is a large scale e-retailer. Much discussion was going on about how the trailer videos for some of their products are not captioned and how this may expose them to litigation by groups such as the National Federation of the Blind (NFB).

This company is fully committed to making their site accessible and if they could not get captioned videos they were going to pull the videos from the site! This is very commendable and it is also very refreshing to see a company with that kind of commitment to accessibility. Unfortunately they had not given much thought to the usability of the site…at least from the accessible view.

After the discussion on video captioning was done I brought up the topic of usability. I was informed that their testing includes the use of JAWS to verify the pages. This again is very commendable. I don’t encounter too many companies that bother to test their sites with a screen reader! Unfortunately the testers making use of this technology are not really attuned on what to check for. They listen to make sure the screen reader is reading out the text and controls but never really ‘hear’ what is being conveyed.

To demonstrate I used this e-retailer’s main landing page and immediately found two issues that a focused usability test pass would have disclosed.

First, products were being displayed with two prices. The retail price formatted with strike through text and then the sales price in bold colored text like this:

$159.99
$99.99

When the screen reader rendered this part of the page the two prices were read equally. There was no indication, other than the visual formatting, to let the user know what the real price of the item was.

Second, an image was used to promote the pre-order of an upcoming release of a product. This simply was comprised of an image which visually provided all the information a user would need to know. Unfortunately the ALT text for this graphic link only said, “Preorder order it now.” This leaves the screen reader user wondering, “Preorder what now?!”

Granted these seem like issues that could easily be figured out by your typical screen reader user but why make the user figure things out? A good user experience means that the site is usable without the second guessing and extra effort needed to investigate what the content really means. This leads to a great user experience, a happy customer and ultimately repeat sales if you are an e-retailer.

Not only does usability lead to a great user experience it also means that you are essentially limiting your exposure to litigation. If an Assistive Technology user can easily access your site, find what they need and make a purchase or retrieve the information they are looking for then why would an organization like the NFB bother with targeting that site for a lawsuit?

I am not saying that ensuring your site is complaint with the standards is not important but it does underscore that usability should be just as important. It helps in making your users happy and in avoiding situations where litigation could become an issue.

If you are expending resources on being compliant do yourself a favor and include usability as part of your accessibility efforts. Should you need help in this area or require an outside consultant to provide this service feel free to contact me and I can point you in the right direction.