Plug-ins resemble applets in the sense that both are software applications that run within the browser. But applets remain separate from the browser; they can be run only from within the page where the <applet> or <object> element invokes them because they require the browser to run the code. Plug-ins can render material such as video clips, 3D animations, and audio files within the browser. In some cases, though, the plug-in acts as a stand-alone application, spawning a new window on the screen and displaying the content in that window. Web authors may have a choice between these two methods; the choice should always be made in favor of greater accessibility, and with sufficient planning, this need not mean sacrificing visual elegance. It is important as well to remember to inform the user that a new window will open to play the media content, just as you would inform him or her of new windows opened for any other reason.
Plug-ins also resemble applets in that they need to be understood from at least two different perspectives.
As Web content, plug-ins are governed by WCAG 1.0, to which we've referred so often throughout this book, and by Section 508's Web accessibility standards (§1194, Chapter 22). Relevant portions of these documents are listed at the beginning of this chapter.
Plug-ins also render Web content. That is, they are user agents, and as such they fall within the purview of the WAI's User Agent Accessibility Guidelines 1.0 (UAAG) and the U.S. Access Board's Software Applications and Operating Systems (§1194, Chapter 21).
Although we will not examine it in great detail, a brief look at UAAG 1.0 will help you understand industry trends in support of accessible plug-ins.
The User Agent Accessibility Guidelines
WCAG 1.0 is just one part of the WAI's comprehensive strategy for achieving Web accessibility. The first step was to integrate better support for accessibility into HTML itself; this effort resulted in the transition from HTML 3.2 to HTML 4.0 (published in December 1997). Next came WCAG 1.0, published as a formal W3C recommendation in May 1999. As we've seen, WCAG provides advice about how to take advantage of the accessibility features in HTML to create more accessible Web content. WCAG 1.0 was followed in February 2000 by the Authoring Tool Accessibility Guidelines 1.0 (ATAG), which explain how authoring tools such as Macromedia Dreamweaver, Microsoft Frontpage, IBM Home Page Builder, and similar tools should make it easier for Web authors including Web authors with disabilities to produce content that conforms to WCAG. Finally, UAAG 1.0 offers recommendations for rendering accessible content in an accessible manner via Web browsers, media players, and other user agents.
The 12 guidelines listed below are taken from the most recent draft of the UAAG, which was published as a W3C Candidate Recommendation on September 12, 2001. Publication of a Candidate Recommendation launches the period in the W3C process during which interested parties can exchange implementation experiences of the specification requirements; at least two implementations of each requirement must be found (or created) before the recommendation can move on to final approval by the W3C membership. A Candidate Recommendation for UAAG is close to final form as of this writing, in June 2002, so we offer the following list of guidelines as the best currently available information.
Support input and output device-independence.
Ensure user access to all content.
Allow configuration not to render some content that may reduce accessibility.
Ensure user control of rendering.
Ensure user control of user interface behavior.
Implement interoperable application programming interfaces.
Observe operating environment conventions.
Implement specifications that benefit accessibility.
Provide navigation mechanisms.
Orient the user.
Allow configuration and customization.
Provide accessible user agent documentation and help. 
 From the Candidate Recommendation of the UAAG published September 12, 2001, at http://www.w3.org/TR/UAAG10/.
Detailed examination of the UAAG and especially of the individual checkpoints that bring each of the guidelines to life is beyond the scope of this book, and indeed it will likely be some time until user agents that implement these recommendations become widely available. Interested readers may wish to see the W3C's "User Agent Implementation Report" at http://www.w3.org/WAI/UA/implementation/report-cr2.html to learn more.
The Section 508 Software Applications and Operating Systems Standards
Until now, we have been referring to Chapter 22 of the Section 508 accessibility standards. When discussing the accessibility of plugins, however, it is more relevant to refer to Chapter 21. We list these provisions below for your information and note that we expect it to be some time before we see a generation of plug-ins that fully meet the standard defined in Section 508, §1194.21.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
(d) Sufficient information about a user interface element including the identity, operation, and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.
(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.
(g) Applications shall not override user-selected contrast and color selections and other individual display attributes.
(h) When animation is displayed, the information shall be dis-playable in at least one non-animated presentation mode at the option of the user.
(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.
(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. 
 From the Section 508 standard published December 2000 at http://www.section508.gov/index.cfm?FuseAction=Content&ID=12.htm#Web.
We won't be discussing these standards in detail. However, UAAG and Section 508, §1194.21, offer a useful angle from which to consider the accessibility of media players and other plug-ins such as Adobe Acrobat Reader. In Chapter 13, we demonstrated techniques that make multimedia content more accessible to users with disabilities. Now let's explore the accessibility of the plug-ins themselves.