OK, folks, here goes nothing.

Let me start this by providing my bit about my background. I’ve been designing, developing and certifying 508 complaint web based trainings for the government departments for the past several years in multiple positions with multiple departments and agencies. This post will not give you a checklist that ensures your project will pass testing – it’s simply an attempt to share what I have learned.

Lesson #1: 508 compliant and 508 certified are not equal statements. 508 complaint indicates the software includes the tools and fields necessary for the developer to create a project that can be certified through a testing protocol. For example if all you do is check the “make accessible” box on a Captivate project, it just turns on all the functionality without creating the correct alt text or names. roles, and states for your interactive objects. It does automatically assign all possibly interactive or accessible objects with alt text – machine generated identifiers that have nothing to do with the content. (More on how to change the gibberish into content in a later entry, perhaps?)

Lesson#2: If you can get a screen reader installed, do it. JAWS is the best answer if you’re designing for the Feds (it’s their default system) but the NVDA screen reader is a close enough approximation if you want a free one instead. If you’ve never used a screen reader, it’s an epiphany when you do. It will also help you understand what is being read and how it sounds to the learner. While using a screen reader is not part of the testing protocol to certify 508 content (at least – not with any group I’ve designed for), it is a tremendous asset in creating truly accessible materials.

Lesson #3: Pre-built interactives are rarely “accessible.” First off, most of the Adobe supplied interactives are built using Flash – and Flash is, by definition, not accessible. You might get away with putting the information into an alt text description, but chances are when the functionality check is being run, two things will happen – tabbing to the object will either skip the object completely (no alt text is read) or the tabbing will highlight the object, then tab into the object and not be able to escape – creating a loop and causing your project to fail testing. If you want interactivity and want accessibility – build your own interactives and set the order and descriptions yourself.

Lesson #4: All 508 testing protocols and checklists are not created equal (and neither are the testers). The testing checklist I am currently using has over 80 possible tests to apply to determine if any multimedia, documents, videos, audio, or software is certifiable. The last departmental checklist I used prior to this one had 115 tests for documents alone. Know what the standard is you are building to and build to it. Find out what tools are being used to test the programs. The Web Accessibility Toolbar (WAT) is a free add on that combines several of the most used and highly regarded accessibility testing programs in one easy to access package. Inspect (part of the Windows SDK package) is another tool I’ve used extensively. You need to know what’s being tested and how it’s being evaluated – otherwise, you can get stuck in a continuous loop of edits and re-edits.

Lesson #5: Text alternatives are losing favor as the “go-to” solution for online courses in many agencies. A well designed and formatted pdf can be a godsend to a visually impaired learner, but two of the last three departments I’ve worked with would not accept these to certify the project – they were viewed as supplemental or flat out unacceptable. In most cases, agency policy has made these the “last resort” for developers. It’s a shame, because if you take the time to create them in a compliant format, they are amazing when you use them with a screen reader.

Lesson #6: Think outside the box. Don’t just “dumb it down” and create a text heavy page turner – that’s not training – that’s surrender. It is not only possible to create interactive training that meets 508 requirements, it can be a rewarding challenge. Designing for 508  requires you to look at the lesson from alternate points of view and find a way to reach learners where they are. In spite of all the warnings I posted in lessons 1-5, there’s a way to move great projects forward without losing the impact you’ve built in for fully able users.

I think that’s a decent start – let me know what kind of follow ups you’d like to see here (if any) and feel free to share your lessons learned as well. The more we share as a community, the better we meet the needs of all of our learners (just like the eLearning Guild says – Together We Are Better, right?) If there’s enough interest, I’ll contuinue this conversation here.