Skip to main content


Beyond HTML: CSS, JavaScript, Plug-ins

This section introduces a few other languages and applications that web designers often use in addition to HTML when creating web sites. It highlights core accessibility issues and strategies for each, and points to outside resources for more information and guidance.

Cascading Style Sheets (CSS)

You can use HTML to control the structure, content and presentation of your web pages. Alternatively, you can leave structure and content to HTML, but control appearance instead with another markup language, Cascading Style Sheets (CSS, or .css files).

Using CSS (also sometimes simply called “style sheets”) to create your page presentation separates page appearance from the page’s content and structure. This has several advantages, including:

  • Web designers no longer have to embed formatting with HTML code around each piece of format. Instead, they can create the formatting rules in a separate style sheet. For example, if a designer wants to increase font size in all paragraphs, in HTML she would have to insert this change in the markup for each paragraph. Using a CSS, she would just have to update the sheet in one place and the change would cascade throughout the affected paragraphs.
  • Users can choose to apply their own style sheet to your site, instead of your sheet, to meet their own access needs. For example, someone with low vision could easily increase the color contrast and font size.

Once you learn how to use it (and it’s not that hard), CSS lets you control your webpage presentation more flexibly and easily, while (potentially) increasing accessibility. Compared with using tables or frames, CSS makes it much easier to control your layout while keeping the content linear and, therefore, accessible to screen readers. You can also use hidden CSS that won’t change your visual impact while making your sites more accessible to users with disabilities.

Figure 10 shows a web page with the host site’s style applied, and then how it looks with the styles removed. For pages styled with CSS such as this one, a user could then apply their own style to make it more useable for them. For example, someone with low vision might set the page to show a large, white font on a black background.


Figure 10: A WebAIM webpage. The first image shows it with the WebAIM CSS style sheet applied.
The second shows the page with styles removed.

Note that even when using CSS, the content and structure you provide with HTML needs to follow the same guidelines as when you aren’t using CSS.

Also, don’t make your pages dependent on CSS – it is only for presentation and appearance. If you try to use it to control page structure, your pages will become less accessible.

Resources on CSS

See WebAIM’s introduction to style sheets at, including a section on using CSS to improve accessibility with content that is invisible to users who don’t need it. The Access E-learning tutorial includes some tips on CSS within their HTML course module at The article at discusses the virtues of CSS vs. tables for layout.

W3schools offers CSS tutorials, 70 examples, and a CSS reference listing at Also, Cornell’s CIT offers face-to-face training sessions on Getting Started with CSS. Visit the technical training schedule available at to see when the next workshop is.


Of the scripting languages, JavaScript may be the most popular. Web designers often embed JavaScripts into their HTML pages to get web pages to do things HTML alone cannot do. For example, designers use it to create pop-up windows, check that all required fields in a form have been filled in, or display changes when you put your mouse over an image.

JavaScript Accessibility Issues14

JavaScript allows developers to add increased interaction, information processing, and control in web-based content. It can even be used to increase accessibility, such as by providing warnings on pages that require a user response or will otherwise time out. However, JavaScript can also introduce accessibility issues. These issues include:

  • Navigation – barriers to navigating using a keyboard or assistive technology.
  • Hidden content – content or functionality not accessible to assistive technologies.
  • User control – lack of user control over automated content changes.
  • Confusion/Disorientation – altering or disabling the normal functionality of the user agent (browser) or triggering events that the user may not be aware of.

Accessible approaches and solutions are:

  • When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
  • Content and functionality that is provided through scripting must be made accessible to assistive technologies.
  • Web pages that use scripting must be fully navigable using a keyboard.
  • JavaScript should not modify or override normal browser functionality in a way that may cause confusion.
  • When JavaScript cannot be made natively accessible, an accessible alternative must be provided, such as with the NOSCRIPT element.

14 This section comes directly and indirectly from

Resources on JavaScript

How to implement each of the approaches and solutions listed above is covered at WebAIM also includes a piece on accessible AJAX, Additional information on accessibility and AJAX is located at You will find a thorough 3-hour self-guided tutorial about accessible scripting, including JavaScripts, as the last module in the free online Access E-Learning course at


Plug-ins are computer programs that interact with a host application, e.g., a web browser, to accomplish a task that the host cannot do on its own. Plug-ins might be used to read particular kinds of files (e.g. using QuickTime to show a video), or play and watch presentations in browser (e.g., watching a Flash presentation).

Three things for web developers or designers to keep in mind about plug-ins are:

  • The plug-in itself must be accessible, i.e., it should work well with assistive technologies. Check with the company that makes the plug-in, or refer to some of the resources below.
  • The content that the plug-in presents needs to be accessible, i.e., it should follow all the other guidelines covered here. For example, most images need alternative text, text should be high contrast, all audio requires transcripts, and all video requires timed captions.
  • Don’t make your important site content or functionality dependent on plug-ins. For example, do not use Flash-only navigation.

Making plug-ins more accessible

Several things you can do to make plug-ins generally more accessible include:

  • Link to the site where the relevant plug-in can be downloaded.
  • When embedding plug-in content and nesting OBJECT and EMBED tags, put the OBJECT tag at the outermost level for Internet Explorer and next the EMBED tag for Netscape browsers.

Resources on Plug-ins

WebAIM compares media players (RealMedia Player, RealOne, Quicktime, and Windows Media Player) in this article: They recommend using players as standalone, rather than embedding them, to make them accessible.

WebAIM also hosts an article about using Flash accessibly, The “Flash and Accessibility” article at provides a bit more detail, and you’ll find checklists at Adobe’s Flash Accessibility information is at

Much of the content in this plugin section is adapted from the Plugin section of the HTML self-training module at That section includes sample HTML for this embedding.