Accessibility Developer Disconnects

I’ve been exploring some accessibility issues and have noticed some disconnects in how accessibility can be implemented. It seems like that the community is making some critical assumptions such that 1) All online content is developed by professionals or that 2) everything is on a PC and 3) that developers are really going to manually disable Flash to check their content.

Online Content from “Non-Professionals”

One of the bigger challenges here at Penn State is that “online content” is actually being developed by instructors and students. In theory, we would like all “online course content” to be accessible, but if that were true literally then we would require that every podcast file be transcribed, every Office document & PDF file be tagged, every page generated by a content management system be accessible, and every image labeled with an ALT tag.

This can be done but it requires time and worse, some specific training. Yes, you can an ALT tag to an image in Word, but you have to know to right click and look for the “Alternative Text” field (and it only works on Window). Similarly, you can tag a PDF file, but you need to check the advanced menus in Acrobat (currently costing about $60) to make sure it is done right. This is much more difficult than clicking a “Convert to PDF” button (and more expensive as well).

The allure of the current online tools is that they are easy. Anyone can make a video, but right now only a few can make one with captions.

Mac Developer/PC User

An quasi disturbing accessibility trend I am noticing is lack of information/ability for Mac developers on how to make output accessible. Although most tools such as the JAWS screen reader assumes a Windows audience, it is a fact that many multimedia developers, particularly those for video or Flash are on a Macintosh.

This wouldn’t be a problem except that the accessibility community seems to write many tutorials assuming everything is produced on Windows. The worst case is Microsoft Office which allows users to add ALT tags to images in Word or Powerpoint…but only in the Windows version. The only way an image in a Mac Word doc can get tagged is to export it to some other format, like HTML.

Many accessibility tools are also Windows only. There’s an excellent Office Accessibility Wizard , but guess what…it only works on Windows. Admitedly, most users are on Windows, but again NOT everyone and possibly NOT developers who might be charged with this (because they are on a Mac). There are locations where multiple platforms are available, but not everyone’s budget can support both…And in any case, it is a major inconvenience to switch between two platforms.

Debugging Flash

Perhaps one of the most serious problems facing accessibility is developing and debugging accessible Flash content. The good news about Flash is that it works across platforms. Which is why it is being incorporated into so many tools from YouTube to Adobe Connect and more. Flash video is truly the wave of the future.

The bad news is that building in accessibility is complex (you need to build in keyboard alternatives, alternative text descriptions for screen readers and check color contrast…somewhere in the application). Worst of all – it’s difficult to discern if the developer has done this. Unlike straight HTML which have checkers like WebAIM WAVE and Cynthia Says, there are no tools to check Flash accessibility without doing something drastic such as disabling the Flash player or testing in JAWS.

There are lots of interesting Web 2.0 tools out there, but it’s very difficult to evaluate if support for screen readers, captioning or keyboarding have been built in without checking the vendor specs or running it on JAWS. If you don’t have JAWS (say, in a Mac only shop) and can’t find vendor specs – you have to assume it’s inaccessible. Too bad.

I may think the application is the coolest thing I have seen in a while, but can I recommend it? Sure, but somewhere in the back in my mind I’m thinking “We need a backup.”

Dreamweaver Model

Although I am describing three different scenarios, they are symptoms of the same problem. At the moment accessibility is treated as a fairly arcane topic requiring lots of technical knowledge and even hacking of code.

I don’t think it has to be this way. One reason I keep recommending Dreamweaver is that their accessibility tools are so easy to find and use. For instance if you drag an image into Dreamweaver, a pop-up window prompts you for an ALT tag. Once you fill in that field, you are done. There are similar prompts for forms, tables and even inserting Flash movies. I suspect that this strategy could be implemented in many more tools such as Word, Flickr or PowerPoint.

Expanding to Flash, could it possible to add more visible prompts to add alt text and keyboard alternatives? It sure would help developers understand that they should be there. The great thing about the prompts is that they recognize that accessibility should be part of the workflow, not an afterthought that only happens if a problem is reported.

Wrapping this blog post, I think my other point is that developers are an important an audience to consider. Browbeating them will only get the community so far (especially if “developers” include teenagers and busy instructors). It really is important to consider how accessibility tools can be just a little more accessible.

This entry was posted in Accessibility. Bookmark the permalink.

One Response to Accessibility Developer Disconnects

  1. Nice post. I too believe that the tools we use could be doing a lot more to improve accessibility from the ground up. I also think that “universal design” (a term I far prefer personally over “accessibility”) should be part of the basic skill set of the modern workforce, no matter what field.

Leave a Reply