Applets, plug-ins, and non-HTML content

Applet and plug-in technologies were developed to deliver non-html coded content to enhance visual, audio, interactive effects, and to deliver other applications in the browser environment. HTML version 4 introduced the OBJECT element as a standard means for encoding other applications. When a Web site or Web application requires execution of these technologies in order to successfully complete tasks or to interpret content, it is important that both the informational content and the user interface be accessible to assistive technologies. In some cases, the user interface and the informational content are part of the same applet, plug-in, or application. For example, Java applets and Flash plug-ins present the user interface as part of the content. In other cases, the user interface is separate from the content. Multimedia plug-ins such as QuickTime, Real Audio, and Windows Media Player; and document reader plug-ins such as Acrobat Reader, have a separate player user interface (play, stop, fast forward, etc.) that controls the playing of the audio, video, or document content. Making the multimedia content accessible is explained in Checkpoint 4: Multimedia for the various audio and video formats. Document content accessibility is explained in Documentation Checkpoint 1 for formats such as Adobe Portable Document Format (PDF).

Applets

Applets are programs designed to be executed or launched from within a Web page. Simple applets can be compatible with screen readers, magnifiers, and other assistive technologies when the user interface is made up of only standard system controls that are supported by assistive technologies. Most text-only browsers, such as Lynx, and most assistive technologies do not support applets. Even when the browser and assistive technology combination support running applets, the content and programming could be implemented in a way that makes it inaccessible to the user. Typically the problem is when the applet uses non-standard controls or when the applet programming extends standard controls to create a custom look. To make applets directly accessible to assistive technology, you must use the techniques in the IBM Java Accessibility Guidelines for Java2 applets and the IBM Software Accessibility Guidelines for all other Java 1.1.x, Visual Basic, C++, etc. software coded applets. If the applet is directly accessible by meeting the Java or software checklist, then alternative content is not required.

Plug-ins:

Select a plug-in that is supported by the browsers and platforms used by your audience and insure that both a plug-in user interface and informational content is accessible. Alternatively provide equivalent content that does not require a plug-in. Some plug-ins are not supported by all browsers on all platforms. Some non-HTML file formats (media types) are supported by more than one plug-in or player. Many multimedia players are supported by Lynx and other assistive technologies such as screen readers, magnifiers, and voice input recognition command and control. Some plug-ins are rendered on the page inside the browser window. Even though these in-line plug-ins have visible controls they may not be operational with the keyboard. Keyboard operation depends on the coding of HTML that launches the plug-in and the plug-in itself. For example the Spacebar will start and stop the playback of the video clip in some plug-ins. By always providing a link to the non-HTML file itself, the chances are greatly increased that an accessible player is available to your audience on their platform that can play the multimedia content. Those plug-in players with a separately launchable user interface outside the browser are responsible for insuring compliance with the IBM Java Accessibility checklist for Java2 plug-ins and the IBM Software Accessibility checklist for all other Java 1.1.x , Visual Basic, C++, etc. software coded plug-ins.

Objects:

The OBJECT element was added to HTML version 4 (link resides outside of ibm.com) and is supported by the newer browsers. The APPLET element was deprecated in favor of the OBJECT element, but is still used on many Web sites and supported by many browsers. Browsers will first try to render the object, but if the browser is not able to render it for any reason (configured not to, wrong platform, not supported, etc.) the browser will try to render the object's contents. Those applications with a separate user interface launched by the OBJECT element outside the browser are responsible for insuring compliance with the IBM Java Accessibility checklist for Java2 objects and the IBM Software Accessibility checklist for all other Java 1.1.x , Visual Basic, C++, etc. software coded objects. 

The following techniques and examples support Checkpoint 6 from the IBM Web Accessibility Checklist.

Applet techniques:

Please Note: Applets, even when they are coded using the techniques below, may still be inaccessible. Existing screen readers do not have the ability to recognize the applet, move focus into the applet, and exit the applet. Therefore, you should consider removing all applets from your websites or providing an accessible alternative method for performing the function.

The following techniques are the minimum required to make applets accessible:

• Add alternative text via the alt attribute to the APPLET element to make the user aware of the applet's purpose. For example:

  <applet code="gravity.class" width="200" height="250" alt="Gravity Calculator">...</applet>

• Make the applet user interface programming and content directly accessible following the appropriate Java Accessibility or Software Accessibility checklist. If the applet is not directly accessible, then the requirement is to provide an equivalent alternative using the following technique:

  • Provide an equivalent alternative for the applet and explain where the alternative is if it is not on the same Web page.

    In the following example, the function of the applet is explained in the text following the applet. Since the function of the applet does not require user interaction, the text explanation is an accessible equivalent:

    
    

    <applet code="spin-lobe.class" width="200" height="250" alt="Spinning Globe">...</applet><p>This applet shows how the earth spins from west to east, but the line of darkness appears to move from east to west.</p>

    
    

    In the following example, the author provides a link to an equivalent alternative that uses familiar forms with processing occurring on the server instead of a client based applet:

    
    

    <applet code="loan-calculator.class" alt="Loan Refinance Calculator">...</applet><p>If the calculator applet is not supported on your browser, link to our <a href="loan-calculator.html">forms based calculator</a> to determine the loan amount.</p>

Plug-in techniques:

One or more of the following techniques are the minimum required to make the plug-in interface and content accessible:

• Select a format that has extensive browser support and provide a link to the source file so the user may choose to launch it separately in an accessible player. For example some screen readers will automatically launch .wav, .rm, .mov, and .txt files.
• Plug-ins that provide interactive content must be operational from the keyboard in order to be directly accessible. Interactive content that is usable only with a mouse is not accessible and requires an equivalent alternative. See the manufacturer's Web site for information about the plug-in's accessibility. For example, for more information about making Flash accessible, see the Macromedia Flash accessibility (link resides outside of ibm.com) Web site.

Note: Video content is accessible to a person who is deaf or hard of hearing, but an equivalent alternative to the visual content is needed by a person who is blind. Audio content is accessible to a person who is blind or has vision impairments, but an equivalent to the audio content is needed by the person who is deaf. See Checkpoint 4: Multimedia for more information about making audio and visual content accessible.

Object techniques:
Make the object programming and content directly accessible following the appropriate Java Accessibility or Software Accessibility checklist. If the object is not directly accessible, then the requirement is to also provide an equivalent alternative using the following technique:

• Include equivalent HTML in the content of OBJECT element. When the object is not supported by the browser or by the assistive technology being used, the HTML content in the OBJECT element is rendered by the browser or made available to the assistive technology.

  In the following example, the function of the Gravity object is explained in the text following the open OBJECT tag. Since the function of the Gravity object does not require user interaction, the text explanation is an accessible equivalent:

  <object classid="java:gravity:class" width="200" height="250"> When gravity acts on an object, the weight...
  </object>
  

  
  

  The following example shows that content of an OBJECT element can be another nested object. The nesting of objects allows the author to specify the order in which the browser should attempt to render the object's contents. The HTML 4 spec on the OBJECT element (link resides outside of ibm.com) provides an example of an object that is a software applet. If that software applet is not supported (configured not to, wrong platform, not installed, etc.) by the browser, the browser will attempt to render the contents of the object, which in this example is a nested object of an MPEG video. If the MPEG video is not supported, then the browser will open the next nested object, which is an animated gif. And finally, if that is not supported, the browser will open the next nested object, which in this example is a text description.

  <!-- First, try the software applet -->
  <object title="IBM sites around the world" classid="ibmworld.class">
  
  <!-- Else, try the MPEG video -->
  <object data="ibmworld.mpeg" type="application/mpeg">
  
  <!-- Else, try the animated GIF -->
  <object data="ibmworld.gif" type="image/gif">
  
  <!-- Else render the text -->
  <p><strong>IBM </strong> is located in the following countries: Argentina, Australia, ... Vietnam.</p>
  </object>
  </object>
  </object>

Test the Web site to ensure that it complies with accessibility requirements.

Additional techniques for testing this checkpoint

Tools

You will need to install the following tools to test this checkpoint:

• A Web accessibility checking tool. Examples of these tools are listed on the Worldwide Web Consortium web site (link resides outside of ibm.com).
• A screen reader that supports Java applets

Techniques

The following techniques are required to verify this checkpoint:

Additional Techniques

In addition to the required tests, these techniques can be used to quickly verify some accessibility features of applets, plug-ins and objects.

• Test pages that contain an applet or object in a browser with support for these features disabled.
• Test the applet with a screen reader to determine if alternative text was added to the APPLET element or the OBJECT content.

For more information on these techniques, see Additional techniques for testing Web accessibility.

Back to top