Web checklist

Checkpoint 2.1c: Applets, plug-ins, and non-HTML content

A link is provided to a directly accessible applet, plug-in or other application. Alternate content is provided for those applets, plug-ins or other applications that are not directly accessible.


Rationale

Applet and plug-in technologies were developed to deliver non-HTML 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 Adobe® 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®, RealAudio®, Windows Media® Player, and document reader plug-ins like Acrobat Reader® have a separate player user interface (play, stop, fast forward, etc.) that controls the playing of the audio, video, or document content.

HTML version 5 introduced the audio and video elements as a standard means for presenting audio and video content in Web pages. HTML5 supports the audio and video elements by leveraging the browser's native player. However, native browser player controls are not keyboard accessible. Therefore, developers must use the HTML5 audio/video API, JavaScript and CSS to implement keyboard focusable controls. An example implementation of an accessible HTML5 video/audio player can be found in chapter 6 of Pro HTML5 Accessibility: Building an Inclusive Web (link resides outside of ibm.com).

Required development and unit test techniques


To comply with this checkpoint, you must meet all of the following techniques.

Make content accessible: Make the HTML5 video , HTML5 audio , applet or object user interface and content directly accessible.

Note: For Web content that is an applet or other non-Flash/Flex object, you must complete the Software accessibility checklist for that content. Use of the HTML5 video or HTML5 audio elements does not require completing the test techniques for the Software Accessibility checklist.

Required unit tests for an applet or other non-Flash/Flex object

The accessibility requirements for Adobe® Flash® and Flex® content have been incorporated into the Web accessibility checklist, so only follow the Flash techniques in each checkpoint.

Note: The examples presented in the techniques are not exhaustive. They are meant to illustrate the spirit of this checkpoint.

Adobe® Flash® examples

Make content accessible: Make the applet's or object's user interface programming and content directly accessible.

To comply with this technique, you must implement the required Flash techniques and examples listed in the other Web accessibility checkpoints. You can also comply with this checkpoint if an accessible alternative to the Flash content is provided.

Required unit tests for Flash development technique 1

Perform the following unit tests using a Web syntax analysis tool or a screen reader.

Note for iOS platform: Mobile Safari does not support Java applets, Flash or other third party plugins. Therefore, equivalent content must be presented in a manner that is accessible on iOS devices. Apple recommends using the HTML5 audio and video elements for audio and video content. However, these elements use the browsers' native players, and the controls on the players are not keyboard accessible. Therefore, developers must use the HTML5 audio/video API, JavaScript and CSS to implement keyboard focusable controls.


IBM® Lotus® Domino® examples

Make content accessible: Make the applet's or object's user interface programming and content directly accessible

You must provide HTML alternatives for all default Java applets shipped with Lotus Domino. When designing a Web application, the Java applets available in Domino can be used to display views, embedded outlines, action bars and rich text fields in a browser. The applets provide a visual interface that is similar to Lotus Notes®. However, the applets are not accessible to anyone who is using a keyboard or an assistive technology like a screen reader. These users will not be able to use the application because it is not accessible.

To comply with this technique, you must implement all of the following examples.

Domino example 1

To make views accessible on the Web, open the View Properties box and select the Advanced tab. In the For Web access section, select "Treat view contents as HTML".

Domino example 2

To make an embedded view accessible on the Web, open the form or page that contains the view. Open the Embedded View Properties box and select the Info tab. In the For Web access section, select "Using HTML" to indicate that the view applet should not be used.

Domino example 3

To make embedded outlines accessible on the Web, open the form or page that contains the embedded outline. Open the Embedded Outline Properties box and select the Info tab. In the For Web access section, select "Using HTML".

Domino example 4

To make action bars accessible on the Web, open the Action Bar Properties box. On the Action Bar Info tab, in the For Web access section, select "Using HTML".

Domino example 5

To make rich text fields accessible on the Web, open the form containing the rich text field. Select the rich text field. Open the Field Properties box and select the Info tab. In the For Web access section, select "Using HTML".

Required unit tests for Domino development technique 1

Perform the following unit tests.


Documentation Examples

Make content accessible: Make the applet's or object's user interface programming and content directly accessible.

To comply with this technique, you must implement the required documentation development and test techniques and examples listed in the Documentation checklist checkpoints.

Documentation example 1

You must check the accessibility of all linked documents. Refer to the Documentation checklist checkpoint 1: Accessible Format, for a list of examples for specific document types.


Recommended development techniques

Although you do not have to implement the recommended techniques in order to comply with this checkpoint, you should review them because they can improve the accessibility and usability of the applets, plug-ins, and non-HTML content.

Recommended example 1

If you are using a plug-in, select a format that has extensive browser support and provide a link to the source file, so a user can launch it separately in an accessible player. For example, a Web browser may automatically launch .wav, .rm, .mov, and .txt files.

Recommended example 2

If you are using an <object> element, 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 the 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 specification 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 as unsupported, wrong platform, not installed, etc.) by the browser, the browser will attempt to render the contents of the object. In this case, the following 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>


©2013 IBM Corporation

Last updated January 1, 2013.

W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/ (link resides outside of ibm.com).
Copyright 1994-2009 W3C (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.