I’ve been to a lot of accessibility meetings since January, and I’ve learned a lot of information, but I’ve also seen a lot of what I call accessibility panic. This is the feeling that results when you’ve learned that you may be responsible for checking your content against a 42-point checklist (AKA WCAG 2.0) that you don’t understand and you’re not sure anyone else does either.
To make it worse, you are hearing all of this from accessibility experts (including myself) who remind you there is a 42-point checklist, and that you will have to learn it ASAP (like we’ve been telling you for some time before any legal issues popped up).
It’s been gently hinted that the above approach may be seen as “Debbie Downerism”, and the truth is, there is some truth in that…and ironically it’s because I’ve been experiencing my own form of accessibility panic.
Feeling The Panic
The scope of making all online material at Penn State, including course files, accessible is important, but there is a lot of steps involved here.
Can we do the following?
- Understand WCAG 2.0 AA requirements including “avoid keyboard traps”
- Explain WCAG 2.0, AA level to anyone?
- Help vendors and Web 2.0 programmers understand the value of accessibility
- Set up appropriate modules for Web professionals, faculty AND staff?
- Persuade instructors to comply?
- Develop an in-house captioning working plan?
- Do I really need to convert all my phonetic symbols to images in LING 404? So far JAWS doesn’t even know they exist/
- Actually provide a concrete timeline?
Sure we can, but first it’s time to panic. Feel the shakes that normally come with 2 cups of coffee. Shake your head in utter confusion as you contemplate verifying sign language access and jargon free English. Groan inwardly as you read another post arguing the finer points of HTML Table accessibility. Laugh silently as you hear the phrase “it can’t be made accessible because it’s on a Mac” (actually it’s sometimes because you don’t put in the right tools on the Mac version…really)
Moving On
It’s true that I sometimes need to overcome my own accessibility panic. I take my coffee break (or maybe a chamomille tea break), but I’m finding that that best cure is just to dig in and find out the specifics.
Some here are some insights that might prove useful.
- If you’re an instructor posting PowerPoint Files, your checklist is short and only involves one new tool (the ALT tagger for images). The rest is stuff instructional designers have been recommending for years (legible fonts, restrained color palettes, a title on every slide…),
- The checklist for ANGEL, Word and Excel is pretty similar. We’re really not expecting faculty to become JavaScript experts anytime soon.
- Some of the more exotic WCAG 2.0 recommendations are level AAA. Great for the best of breed accessibility, but usually not needed for most cases.
If you’re a Webmaster, there is definitely more to learn, but some of it is pretty darn useful really. If you know your tags and your CSS you can develop some fairly elegant, but code-streamlined interfaces. It’s sound implausible, but there are some coding accessibility challenges I truly enjoy.
I’ll also confess that captioning is not something I look forward to, but I have forced myself to sit through it a few times, and I’ve even found some benefits there too (e.g. a transcript can help you pick out the good quotes quickly once you’ve listened to the whole thing). While we probably won’t have time to hand caption every videos, I am glad I understand the process.
I don’t know if this blog posting will make anyone feel better, but it’s been a good exercise for me. Just know that when some of us are making recommendations, we’ve been there too cleaning up old content and testing new items on a screen reader.
In my case, I’ve been able to leverage that to learn a lot more about technology that I thought ever dig into.