Most non-graphical browsers do not support applets or many plug-ins. You need to be sure your pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, you should inform the user of the existence of the applet and provide an alternative accessible solution.

• applets
• scripts
• Flash
• Adobe PDF

Equivalents for Applets and programmatic elements|

Applets are programs designed to be executed or launched from within a web page. Ideally, an applet should be designed to be accessible and be usable via keyboard or mouse. The text content of an applet is inaccessible to screen readers. Information can be provided in the ALT attribute of the <applet> tag, eg if a separate text-only page is necessary, use the ALT attribute to state this:

• Add alternative text to the APPLET element to inform the user of the applet and also a description of what the applet does, eg:
  <applet code="gravity.class" width="200" height="250" alt="Java gravity applet. Text alternative available via link at top of page."></applet>
  However, this works only for browsers that support Java. Because some browsers do not accept Java applets, you should also include alternative text between opening and closing <APPLET> or <OBJECT> tags, eg:
  <applet code="gravity.class" width="200" height="250" alt="Java gravity applet. Text alternative available via link at top of page.">Java gravity applet. Text alternative available via link at top of page.</applet>

• If OBJECT is used, provide a text equivalent in the content of the element. See W3C's Text and non-text equivalents for applets and programmatic objects for more information.

Directly accessible applets

Makeprogrammatic elements such as scripts and applets directly accessible| or compatible with assistive technologies - required if functionality is important and not presented elsewhere

The following resources can help you ensure your applets are accessible:

• Java Accessibility - Trace R&D Center IBM Guidelines for Writing
• Sun's Java Accessibility API
• Java Accessibility - IBM Accessibility Center & Sun Microsystems' Accessibility group

Plug-ins

Many plug-in technologies were developed to support new visual and audio effects. The use of video clips of interviews or news Webcasts will be meaningless to someone who cannot hear, unless there are subtitles or captions. If your site requires audio or visual, make sure you select a format (such as .wav or .mov) that has extensive browser support (IBM's Home Page Reader will automatically launch .wav files). See Multimedia| for more information about making audio and visual content accessible.

Adobe Flash Content 

• Flash should be used with care. It requires a plug in and Flash content tends not to be frequently updated.
• Flash introductions delay users getting to what they came for; you can use of the 'skip intro' button but be sure that you do not include this within the movie itself otherwise your site will remain inaccessible
• Flash breaks web fundementals - link colours/Back button/Text resize/Find in page don't work

For more information about making Flash accessible see the Adobe site on Flash accessibility|.

Portable Document Formats (PDFs) and Adobe's accessibility tools

PDF's are becoming more and more accessible, view information on PDF Accessibility on the Adobe website; the Adobe Accessibility Resource Centre|. If you make a document available in PDF format, you should make sure that you include a link to these tools in addition to a link to download the Acrobat plug-in|.

Testing for Applets and Plug-ins

Test pages in a browser that does not support applets and plug-ins, or test pages in a browser with support for these features disabled (to do this in Netscape, click Edit-Preferences-Advanced and uncheck 'Enable Java'; in IE, click Tools-Internet Options-Security; click Custom Level, scroll down to the Scripting section and cancel applets).

Scripting

Scripting on Web pages, specifically JavaScript (and the standards version ECMAScript) are now better supported by assistive technologies. JavaScript mouseovers used for visual effects (eg highlighting) can, in some cases, actually improve usability. You should aim to make scripts accessible from the keyboard and the content (different from functionality) available to the assistive technology.

Alternatives for Scripts

If scripts are used to create content, and the user's browser does not support scripts, no content is generated or rendered. If the script functionality and content is not accessible, techniques to ensure alternatives to scripts include:

• The NOSCRIPT element contains HTML markup that will be displayed by browsers that do not support scripting or browsers with scripting turned off. In addition to alternative content, the NOSCRIPT element can also contain a link to an alternative accessible Web page with the same content. For example:
  ...
  <noscript>
  <br><A href="alternative.htm">Link to Alternative page</A>
  </noscript>
  
• Use a server-side script in place of/in addition to a client-side script
• Provide an equivalent alternative page that is accessible.

Alternatives for Scripts Using Event Handlers

Ensure that there are alternatives for links that can only be activated by an event handler. An event handler is a script that is invoked when a certain event occurs (eg the mouse moves over a link (onmouseover), a key is pressed, the document is loaded, etc.). In HTML 4.01, event handlers are attached to elements via event handler attributes (the attributes beginning with "on", as in "onkeyup"). Some event handlers merely change the presentation of an element; others can, for example, submit a form,.perform a calculation or provide important information to the use. For these event handlers you should:

• Use "onfocus", "onblur" and "onselect" - these attributes are called application-level event attributes; they are designed to be device-independent
• Otherwise, provide redundant input mechanisms eg use "onclick" with "onkeypress". Do not use double-clicking ("ondblclick") - there is no keyboard equivalent in HTML 4.01.
• Do not write event handlers that rely on the mouse because this will prevent device-independent input.

Testing

• Test the page with Internet Explorer using only the keyboard (no mouse) to test the functionality of the site. If the script is accessible, you will be able to access and activate the script on the page using only the keyboard commands and the site will be fully functional.
• Test pages in a browser that does not support scripts or test pages in a browser with support for these features disabled [in Netscape, click Edit-Preferences-Advanced and clear the options that enable Javascript uncheck 'Enable Java'; in IE, click Tools-Internet Options-Security; click Custom Level, scroll down to the Scripting section to cancel scripts] if the NOSCRIPT element or equivalent alternative were used, the supported content will be available.