Overview of Accessible Technologies

Abstract

Web technologies aren't accessible by chance. When a new technology is developed, inattention to accessibility translates most often to inaccessible technology. The fact that the Web and the technologies used to interact with it are ever-changing means that it demands constant monitoring in order to ensure that the needs of users with disabilities are not ignored. More often than not, even with constant monitoring, access to new technologies lags well behind their large-scale adoption-a fact that is not lost on users with disabilities. The excitement felt and expressed by many developers about a new strategy or technology is infectious. Articles and blog entries are churned out by the hundreds, and product strategies shift to take advantage of the interest. Eventually, somewhere, a few people ask, "Is this accessible?" From there (and assuming the answer is, in large part, no), the process is neither rapid nor linear. Concerned developers need to learn about the strengths and limitations of a technology in order to maximize accessibility. Assistive technologies need to create new ways to interpret information from and interact with this technology. Users need to acquire and learn how to use new and improved versions of assistive technologies. These events occur iteratively, improving access incrementally, but with plenty of frustration for users and developers along the way. As a result of this indirect route toward providing access, whether a technology is regarded as accessible is often subjective. The World Wide Web Consortium's (W3C's) Synchronized Multimedia Integration Language (SMIL) is usually regarded as an accessible technology, but no assistive technologies are able to interact with buttons in a media presentation. SMIL does provide the best way to add closed captions and audio descriptions to media for Real Media players, and few developers use SMIL for anything more than linear media layout and display, so screen reader and even keyboard access is not frequently an issue. Flash, on the other hand, usually includes interactive elements and non-linear or interrupted-linear media. Authoring accessible Flash requires some knowledge on the part of the developer, so it is not unusual to encounter Flash content that has been authored inaccessibly. As a result, Flash, while enjoying greater accessibility support in screen readers than SMIL and having similar capabilities for captions and audio descriptions , is often regarded as an inaccessible format. We'll look into both SMIL and Flash in this chapter. Excluding users is never the intended goal when choosing any technology for a project, but you will almost always bar access for some. There are always users who don't own the latest version of a screen reader, who don't use a browser that supports JavaScript, who use Windows 3.1, or who access the Web using their mobile phone. The best you can do is choose the most accessible technology that is appropriate for your content and business needs. When using a newer or less accessible technology, you can make good efforts to ensure that your website or application degrades gracefully and retains comparable func-tionality for users who don't have the targeted configuration of hardware and software. In this chapter, I will discuss many different technologies and highlight accessibility benefits and shortcomings for each. I'll put my stake in the ground and indicate whether or not the technology is accessible. If the technology is not accessible, it doesn't necessarily mean that you shouldn't use it, but that you should provide alternative ways to access the WEB ACCESSIBILITY: WEB STANDARDS AND REGULATORY COMPLIANCE 86 content. My opinion-built with knowledge of the state of assistive technologies, browsers, players, and development strategies that exist in 2006-is certainly subject to change, and I am hopeful that it will do so.