With the World Wide Web still being relatively young, it is amazing how much it has developed in the past 10 years. The web in its infancy was explored using text only browsers such as lynx. These browsers were limited in functionality, and were usually restricted to simple textual information, most commonly in the form of HTML files.
In 1992, Marc Andreessen wrote the first version of x-mosaic. Mosaic is credited with introducing the ability to view inline images; its graphical nature would become the impetus for the web explosion that occurred in the mid-90's. In 1993 and 1994, Mosaic's popularity exploded, helping define the World Wide Web as you know it today.
Today, web browsers are capable of handling various file formats, usually with the help of a plug-in. Plug-ins are usually written by third-party developers, and are 'helper programs' for the web browser - essentially expanding its functionality. It is usually necessary to download and install a plug-in if the browser encounters a file format it does not recognize. If a particular file format becomes popular enough, sometimes it is bundled with the web browser.
There are two kinds of plug-ins on which a web developer should focus on:
It is up to the developer of either plug-in to ensure that it meets software accessibility guidelines.
One thing that developers should keep in mind is that several
individuals still use a text-only web browser that may not be able to support
plug-ins. This is why some argue that plug-ins are not accessible. One approach
to satisfy both parties is to provide an accessible HTML version of the content.
In fact, the Web Accessibility
Initiative
says "When inaccessible technologies (proprietary or not) must be used,
equivalent accessible pages must be provided." This is especially true
when plug-in content is used for navigation. Having to create equivalent pages
can put a serious strain on the developer because of the maintainability issue;
updating one site requires that the other accessible site be updated consistently.
If you are a web developer, you should know three things about plug-ins:
There are several things you can do to make working with plug-ins easier:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub
/shockwave/cabs/flash/swflash.cab#version=5,0,0,0"
width=366 height=142 id="myFlash">
<param name=movie value="../Labs.swf">
<param name=quality value=high>
<param name="swliveconnect" value="true">
<embed src="../Labs.swf"
quality="high" width="366" height="142"
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/downloads/"
name="myFlash"
swliveconnect="true">
</embed>
</object>
A plug-in can claim it is accessible if it meets certain software
accessibility specifications. These specifications require that the content
the plug-in is trying to render can be exposed to assistive technologies. Keep
in mind that just because the plug-in is accessible does not mean the developer
of the content designed it in an accessible fashion. Adobe
Acrobat Reader
and Macromedia
Flash Player
are two common plug-ins that are known to have made great strides in accessibility,
and are considered to be mostly accessible. Other common plug-ins include:
These technologies appear to be only partially accessible. Again, the developer should understand that using plug-ins means that the site will be less accessible, but for users with disabilities that have more modern browsers, some plug-ins have near accessibility.
The next page will discuss image maps in HTML.
College of Architecture (COA)
Fax: 404-894-9320
Phone: 404-894-4960 (v/tty)
User Agreement
HTML
Plug-ins
Previous Page
