Part1: Introducing Android 4.0 - Simple, Beautiful, Useful

Introducing Android 4.0

Android 4.0 (Ice Cream Sandwich) is the latest version of the Android platform for phones, tablets, and more. It builds on the things people love most about Android — easy multitasking, rich notifications, customizable home screens, resizable widgets, and deep interactivity — and adds powerful new ways of communicating and sharing.

Simple, Beautiful, Useful

Refined, evolved UI

Focused on bringing the power of Android to the surface, Android 4.0 makes common actions more visible and lets you navigate with simple, intuitive gestures. Refined animations and feedback throughout the system make interactions engaging and interesting. An entirely new typeface optimized for high-resolution screens improves readability and brings a polished, modern feel to the user interface.
Virtual buttons in the System Bar let you navigate instantly to Back, Home, and Recent Apps. The System Bar and virtual buttons are present across all apps, but can be dimmed by applications for full-screen viewing. You can access each application's contextual options in the Action Bar, displayed at the top (and sometimes also at the bottom) of the screen.
Multitasking is a key strength of Android and it's made even easier and more visual on Android 4.0. The Recent Apps button lets you jump instantly from one task to another using the list in the System Bar. The list pops up to show thumbnail images of apps used recently — tapping a thumbnail switches to the app.

The Recent Apps list makes multitasking simple.

Jump to the camera or see notifications without unlocking.

For incoming calls, you can respond instantly by text.

Rich and interactive notifications let you keep in constant touch with incoming messages, play music tracks, see real-time updates from apps, and much more. On smaller-screen devices, notifications appear at the top of the screen, while on larger-screen devices they appear in the System Bar.

Home screen folders and favorites tray

New home screen folders offer a new way for you to group your apps and shortcuts logically, just by dragging one onto another. Also, in All Apps launcher, you can now simply drag an app to get information about it or immediately uninstall it, or disable a pre-installed app.

The All Apps launcher (left) and resizable widgets (right) give you apps and rich content from the home screen.

On smaller-screen devices, the home screen now includes a customizable favorites tray visible from all home screens. You can drag apps, shortcuts, folders, and other priority items in or out of the favorites tray for instant access from any home screen.

Resizable widgets

Home screens in Android 4.0 are designed to be content-rich and customizable. You can do much more than add shortcuts — you can embed live application content directly through interactive widgets. Widgets let you check email, flip through a calendar, play music, check social streams, and more — right from the home screen, without having to launch apps. Widgets are resizable, so you can expand them to show more content or shrink them to save space.

New lock screen actions

The lock screens now let you do more without unlocking. From the slide lock screen, you can jump directly to the camera for a picture or pull down the notifications window to check for messages. When listening to music, you can even manage music tracks and see album art.

Quick responses for incoming calls

When an incoming call arrives, you can now quickly respond by text message, without needing to pick up the call or unlock the device. On the incoming call screen, you simply slide a control to see a list of text responses and then tap to send and end the call. You can add your own responses and manage the list from the Settings app.

Swipe to dismiss notifications, tasks, and browser tabs

Android 4.0 makes managing notifications, recent apps, and browser tabs even easier. You can now dismiss individual notifications, apps from the Recent Apps list, and browser tabs with a simple swipe of a finger.

A spell-checker lets you find errors and fix them faster.

A powerful voice input engine lets you dictate continuously.

Improved text input and spell-checking

The soft keyboard in Android 4.0 makes text input even faster and more accurate. Error correction and word suggestion are improved through a new set of default dictionaries and more accurate heuristics for handling cases such as double-typed characters, skipped letters, and omitted spaces. Word suggestion is also improved and the suggestion strip is simplified to show only three words at a time.
To fix misspelled words more easily, Android 4.0 adds a spell-checker that locates and underlines errors and suggests replacement words. With one tap, you can choose from multiple spelling suggestions, delete a word, or add it to the dictionary. You can even tap to see replacement suggestions for words that are spelled correctly. For specialized features or additional languages, you can now download and install third-party dictionaries, spell-checkers, and other text services.

Powerful voice input engine

Android 4.0 introduces a powerful new voice input engine that offers a continuous "open microphone" experience and streaming voice recognition. The new voice input engine lets you dictate the text you want, for as long as you want, using the language you want. You can speak continously for a prolonged time, even pausing for intervals if needed, and dictate punctuation to create correct sentences. As the voice input engine enters text, it underlines possible dictation errors in gray. After dictating, you can tap the underlined words to quickly replace them from a list of suggestions.

Data usage controls let you monitor total usage by network type and application and then set limits if needed.

Control over network data

Mobile devices can make extensive use of network data for streaming content, synchronizing data, downloading apps, and more. To meet the needs of you with tiered or metered data plans, Android 4.0 adds new controls for managing network data usage.
In the Settings app, colorful charts show the total data usage on each network type (mobile or Wi-Fi), as well as amount of data used by each running application. Based on your data plan, you can optionally set warning levels or hard limits on data usage or disable mobile data altogether. You can also manage the background data used by individual applications as needed.

Designed for accessibility

A variety of new features greatly enhance the accessibility of Android 4.0 for blind or visually impaired users. Most important is a new explore-by-touch mode that lets you navigate without having to see the screen. Touching the screen once triggers audible feedback that identifies the UI component below; a second touch in the same component activates it with a full touch event. The new mode is especially important to support users on new devices that use virtual buttons in the System Bar, rather than dedicated hardware buttons or trackballs. Also, standard apps are updated to offer an improved accessibility experience. The Browser supports a script-based screen reader for reading favorite web content and navigating sites. For improved readability, you can also increase the default font size used across the system.
The accessibility experience begins at first setup — a simple touch gesture during setup (clockwise square from upper left) activates all accessibility features and loads a setup tutorial. Once accessibility features are active, everything visible on the screen can be spoken aloud by the standard screen reader.

Contacts and profiles are integrated across apps and social networks, for a consistent, personal experience everywhere — from incoming calls to emails.

Communication and sharing

People and profiles

Throughout the system, your social groups, profiles, and contacts are linked together and integrated for easy accessibility. At the center is a new People app that offers richer profile information, including a large profile picture, phone numbers, addresses and accounts, status updates, events, and a new button for connecting on integrated social networks.
Your contact information is stored in a new "Me" profile, allowing easier sharing with apps and people. All of your integrated contacts are displayed in an easy to manage list, including controls over which contacts are shown from any integrated account or social network. Wherever you navigate across the system, tapping a profile photo displays Quick Contacts, with large profile pictures, shortcuts to phone numbers, text messaging, and more.

Unified calendar, visual voicemail

To help organize appointments and events, an updated Calendar app brings together personal, work, school, and social agendas. With user permission, other applications can contribute events to the calendar and manage reminders, for an integrated view across multiple calendar providers. The app is redesigned to let you manage events more easily. Calendars are color-coded and you can swipe left or right to change dates and pinch to zoom in or out agendas.
In the phone app, a new visual voicemail features integrates incoming messages, voice transcriptions, and audio files from one or more providers. Third-party applications can integrate with the Phone app to add your own voice messages, transcriptions, and more to the visual voicemail inbox.

Capture the picture you want, edit, and share instantly.

Rich and versatile camera capabilities

The Camera app includes many new features that let you capture special moments with great photos and videos. After capturing images, you can edit and share them easily with friends.
When taking pictures, continuous focus, zero shutter lag exposure, and decreased shot-to-shot speed help capture clear, precise images. Stabilized image zoom lets you compose photos and video in the way you want, including while video is recording. For new flexibility and convenience while shooting video, you can now take snapshots at full video resolution just by tapping the screen as video continues to record.
To make it easier to take great pictures of people, built-in face detection locates faces in the frame and automatically sets focus. For more control, you can tap to focus anywhere in the preview image.
For capturing larger scenes, the Camera introduces a single-motion panorama mode. In this mode, you start an exposure and then slowly turn the Camera to encompass as wide a perspective as needed. The Camera assembles the full range of continuous imagery into a single panoramic photo.
After taking a picture or video, you can quickly share it by email, text message, bluetooth, social networks, and more, just by tapping the thumbnail in the camera controls.

A Photo Gallery widget on the home screen.

Redesigned Gallery app with photo editor

The Gallery app now makes it easier to manage, show, and share photos and videos. For managing collections, a redesigned album layout shows many more albums and offers larger thumbnails. There are many ways to sort albums, including by time, location, people, and tags. To help pictures look their best, the Gallery now includes a powerful photo editor. You can crop and rotate pictures, set levels, remove red eyes, add effects, and much more. After retouching, you can select one or multiple pictures or videos to share instantly over email, text messaging, bluetooth, social networks, or other apps.
An improved Picture Gallery widget lets you look at pictures directly on the home screen. The widget can display pictures from a selected album, shuffle pictures from all albums, or show a single image. After adding the widget to the home screen, you can flick through the photo stacks to locate the image you want, then tap to load it in Gallery.

Live Effects let you change backgrounds and use Silly Faces during video.

Live Effects for transforming video

Live Effects is a collection of graphical transformations that add interest and fun to videos captured in the Camera app. For example, you can change the background behind them to any stock or custom image, for just the right setting when shooting video. Also available for video is Silly Faces, a set of morphing effects that use state-of-the-art face recognition and GPU filters to transform facial features. For example, you can use effects such as small eyes, big mouth, big nose, face squeeze, and more. Outside of the Camera app, Live Effects is available during video chat in the Google Talk app.

Snapping a screenshot.

Sharing with screenshots

You can now share what's on your screens more easily by taking screenshots. Hardware buttons let them snap a screenshot and store it locally. Afterward, you can view, edit, and share the screen shot in Gallery or a similar app.

Cloud-connected experience

Android has always been cloud-connected, letting you browse the web and sync photos, apps, games, email, and contacts — wherever you are and across all of your devices. Android 4.0 adds new browsing and email capabilities to let you take even more with them and keep communication organized.

The Browser tabs menu (left) lets you quickly switch browser tabs. The options menu (right) gives you new ways to manage your browsing experience.

Benchmark comparisons of Android Browser.

Powerful web browsing

The Android Browser offers an experience that’s as rich and convenient as a desktop browser. It lets you instantly sync and manage Google Chrome bookmarks from all of your accounts, jump to your favorite content faster, and even save it for reading later in case there's no network available.
To get the most out of web content, you can now request full desktop versions of web sites, rather than their mobile versions. You can set your preference for web sites separately for each browser tab. For longer content, you can save a copy for offline reading. To find and open saved pages, you can browse a visual list that’s included with browser bookmarks and history. For better readability and accessibility, you can increase the browser’s zoom levels and override the system default text sizes.
Across all types of content, the Android Browser offers dramatically improved page rendering performance through updated versions of the WebKit core and the V8 Crankshaft compilation engine for JavaScript. In benchmarks run on a Nexus S device, the Android 4.0 browser showed an improvement of nearly 220% over the Android 2.3 browser in the V8 Benchmark Suite and more than 35% in the SunSpider 9.1 JavaScript Benchmark. When run on a Galaxy Nexus device, the Android 4.0 browser showed improvement of nearly 550% in the V8 benchmark and nearly 70% in the SunSpider benchmark.

Improved email

In Android 4.0, email is easier to send, read, and manage. For composing email, improved auto-completion of recipients helps with finding and adding frequent contacts more quickly. For easier input of frequent text, you can now create quick responses and store them in the app, then enter them from a convenient menu when composing. When replying to a message, you can now toggle the message to Reply All and Forward without changing screens.
For easier browsing across accounts and labels, the app adds an integrated menu of accounts and recent labels. To help you locate and organize IMAP and Exchange email, the Email app now supports nested mail subfolders, each with synchronization rules. You can also search across folders on the server, for faster results.
For enterprises, the Email app supports EAS v14. It supports EAS certificate authentication, provides ABQ strings for device type and mode, and allows automatic sync to be disabled while roaming. Administrators can also limit attachment size or disable attachments.
For keeping track of incoming email more easily, a resizable Email widget lets you flick through recent email right from the home screen, then jump into the Email app to compose or reply.

Android Beam lets you share what you are using with a single tap.

Innovation

Android is continuously driving innovation forward, pushing the boundaries of communication and sharing with new capabilities and interactions.

Android Beam for NFC-based sharing

Android Beam is an innovative, convenient feature for sharing across two NFC-enabled devices, It lets people instantly exchange favorite apps, contacts, music, videos — almost anything. It’s incredibly simple and convenient to use — there’s no menu to open, application to launch, or pairing needed. Just touch one Android-powered phone to another, then tap to send.
For sharing apps, Android Beam pushes a link to the app's details page in Android Market. On the other device, the Market app launches and loads the details page, for easy downloading of the app. Individual apps can build on Android Beam to add other types of interactions, such as passing game scores, initiating a multiplayer game or chat, and more.

Face recognition lets you unlock your phone with your face.

Face Unlock

Android 4.0 introduces a completely new approach to securing a device, making each person's device even more personal — Face Unlock is a new screen-lock option that lets you unlock your device with your face. It takes advantage of the device front-facing camera and state-of-the-art facial recognition technology to register a face during setup and then to recognize it again when unlocking the device. Just hold your device in front of your face to unlock, or use a backup PIN or pattern.

Wi-Fi Direct and Bluetooth HDP

Support for Wi-Fi Direct lets you connect directly to nearby peer devices over Wi-Fi, for more reliable, higher-speed communication. No internet connection or tethering is needed. Through third-party apps, you can connect to compatible devices to take advantage of new features such as instant sharing of files, photos, or other media; streaming video or audio from another device; or connecting to compatible printers or other devices.
Android 4.0 also introduces built-in support for connecting to Bluetooth Health Device Profile (HDP) devices. With support from third-party apps, you can connect to wireless medical devices and sensors in hospitals, fitness centers, homes, and elsewhere.

First Data Global Payment Gateway for Magento by Booklink

Magento Go, Part 5: Configurable Products - Managing Images

Creating Accessible JavaScript

Overview of Creating Accessible JavaScript

Article Contents

1. Current page: Page 1: Overview of Creating Accessible Javascript
   1. What is JavaScript?
   2. JavaScript Accessibility Issues
      1. JavaScript that does not impact accessibility
   3. Comparison of JavaScript Guidelines
   4. Testing for JavaScript Reliance
      1. Disabling JavaScript
2. Page 2: JavaScript Event Handlers
3. Page 3: Other Issues
4. Page 4: JavaScript Alternatives
5. Page 5: Accessible JavaScript Summary

What is JavaScript?

This may best be answered by defining what JavaScript is NOT. First, it is not HTML. JavaScript does not use HTML tags or abide by any of the general rules of the HTML language. You can, however, use JavaScript with HTML on a webpage. Second, JavaScript is not Java. Although JavaScript is often called Java, the two are not the same. Java was developed by Sun Microsystems and is a stand-alone programming language. JavaScript, on the other hand, was developed by Netscape Corporation. Although similar to Java in syntax, JavaScript is not a stand-alone language; in order for JavaScript to work, it must be part of a web page that is being displayed in a browser that understands the JavaScript language. Sun's Java programming language can be implemented in webpages as a built in program, whereas JavaScript scripts are reliant upon the client (visitor's) computer in order for them to work.

Once again, JavaScript is not HTML or a version of HTML. It is a distinct, separate scripting language. HTML is read and processed by the web browser. When the browser reads JavaScript code within your HTML document, it processes the code, then displays any output within the web page. The computer reading the JavaScript must have a JavaScript interpreter, a program that interprets the script and runs it, and that interpreter must be enabled.

HTML, alone, creates very static pages. There is little user interaction and little by the way of dynamic content within a particular page. HTML cannot think; it does not have the capabilities to perform mathematics, store variables, or dynamically display content. JavaScript allows your web page to 'think'. Although many server-side scripting programs (such as PHP, JPS, ASP, or ColdFusion) have the ability to perform such functions, JavaScript can perform these functions within the client web browser. Because JavaScript is a scripting language, it allows developers to implement little applications into their pages. These programs may do things as simple as changing a graphic when the mouse rolls over it to something as complex as performing advanced mathematical formulas on user input.

JavaScript Accessibility Issues

JavaScript allows developers to add increased interaction, information processing, and control in web-based content. However, JavaScript can also introduce accessibility issues. These issues include:

• Navigation. Inability or difficulty navigating using a keyboard or assistive technology.
• Hidden content. Presentation of content or functionality that is 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.

A web page containing JavaScript will typically be fully accessible if the functionality of the script is device independent (does not require only a mouse or only a keyboard) and the information (content) is available to assistive technologies. Unfortunately, there is no easy fix that can be applied to solve all accessibility problems associated with JavaScript. The only way to ensure JavaScript accessibility is by evaluating each individual script and devising a unique solution to the accessibility problem it poses. Developers must be familiar with the issues surrounding JavaScript accessibility and apply techniques to do one or both of the following:

1. Ensure the JavaScript is directly accessible
2. Provide an accessible, non-JavaScript alternative

JavaScript that does not impact accessibility

Just because JavaScript is utilized on a page does not mean that the page is inaccessible. In many cases, JavaScript can be used to increase accessibility. Additional information, warnings, or instructions can be given to users through JavaScript prompts. For instance, under the Section 508 guidelines of United States law, a user must be notified when a timed response is required and given sufficient time to indicate more time is required. Such functionality would be difficult with HTML alone.
JavaScript is sometimes used to create visual interface elements that do not affect accessibility. JavaScript is commonly used for image rollovers, where one image is replaced with another when the mouse is placed above it; for example, when a navigation item changes to display a shadow, glow, or highlight when the user mouses over it.

Place your mouse over the following image to see a JavaScript example that does not impact accessibility.

Problems

None. In this example, there is no important content or functionality introduced by the JavaScript. The swapping of images is purely cosmetic.

Solution

No additional accessibility techniques are required. Remember, the image itself must have alternative text (i.e., <img alt="home"...>). You can also accomplish image rollovers without using JavaScript - external link.

Such uses of JavaScript do not need additional accessibility features incorporated because important content is not displayed or functionality introduced by such scripting.
Making JavaScript accessible involves looking at the following issues. Each of these will be discussed in the next lessons.

• 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 utilize 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.

Comparison of JavaScript Guidelines

Section 508 of the Rehabilitation Act (in the United States) and the W3C Web Content Accessibility Guidelines (WCAG) 1.0 both address the accessibility of scripting elements. They require that the functionality and content of scripts be accessible to assistive technologies such as screen readers. Additionally, users must be given control over time-based content changes. There are, however, differences between the two accessibility guidelines. WCAG requires that content and functionality be accessible with scripting disabled and that users should be alerted if JavaScript changes the appearance or functionality of the browser window, whereas Section 508 only requires that the scripting be made accessible or that an accessible alternative is provided.

Testing for JavaScript Reliance

As mentioned above, your web pages should be fully functional with JavaScript disabled. This is required under Priority 1 of the Web Content Accessibility Guidelines. Section 508 does not require the page to function if JavaScript is disabled, but does require that the scripts themselves be natively accessible. This tutorial will teach strategies for making your scipts natively accessible and assumes that if you, as a developer, want to achieve a higher level of accessibility or comply with the Web Content Accessibility Guidelines, that you will also test your pages to ensure that they work with JavaScript disabled.

Disabling JavaScript

Follow the directions to disable or enable JavaScript in your browser. You can also determine if JavaScript is disabled. Test a JavaScript enabled web page and see if the content and functionality are accessible. Be sure to re-enable JavaScript when you're done.
Internet Explorer 6.X

1. Open Internet Explorer.
2. Select Tools > Internet Options.
3. In Internet Options dialog box select the Security tab.
4. Click Custom Level button at bottom. The Security Settings dialog box will pop up.
5. Under the Scripting category, enable/disable Active Scripting, Allow paste options via script and Scripting of Java applets.
6. Click OK twice to close out.
7. Click Refresh.

Netscape 7.X

1. Open Netscape.
2. Select Edit > Preferences.
3. Click the arrow next to Advanced.
4. Click Scripts & Plugins.
5. Check/uncheck Navigator beneath "Enable Javascript for".
6. Click OK.
7. Click Reload.

Opera 7.X

1. Open Opera.
2. Select File > Quick Preferences.
3. Check/uncheck Enable Javascript.
4. Click Reload. 

Overview

JavaScript can be processed using <script> elements and event handlers. The <script> element can contain JavaScript code directly:

<script type="text/javascript"> <!-- function doit(); --> </script>

or can open an external JavaScript (.js) file:

<script type="text/javascript" src="scripts.js">

The <script> element is processed when the page is loaded and requires no user intervention. The contents and functionality of the script processed within the <script> element must be directly accessible or an accessible alternative of the content and functionality must be provided.
Event handlers accompany existing HTML code and are triggered by a browser or user event - such as when the page loads, when the user clicks the mouse, or when the time is 8 p.m. Some event handlers are dependent upon use of a mouse or keyboard. These are called device dependent event handlers. Other event handlers are device independent and are triggered by both the mouse and keyboard or by other means. Using device dependent event handlers may cause the content to be inaccessible to someone that is not able to use the device that is required for that specific event handler.

onMouseOver and onMouseOut

The onMouseOver event handler is triggered when the mouse cursor is placed over an item. As its name implies, onMouseOver requires the use of a mouse, thus it is a device dependent event handler and may cause accessibility issues. onMouseOver, and its companion, onMouseOut, can be used, as long as any important content or functionality is also available without using the mouse.

Example 1

Place your mouse over the following image to see an example of onMouseOver. When the mouse is placed over the image of the word "Accessibility", another image appears in its place which presents the definition of the word "Accessibility".

<a href="page.htm" onmouseover="document.images['myimage'].src='imageoff.gif';" onmouseout="document.images['myimage'].src='imageon.gif';"> <img src="media/imageoff.gif" width="289" height="79" id="myimage" alt="Accessibility - The quality of being accessible, or of admitting approach; receptibility." /> </a>

Important
All of the examples in this lesson are coded to be XHTML 1.0 Strict compliant. XHTML requires lower-case event handler names (e.g., onmouseover instead of onMouseOver).

Try navigating to the image using the keyboard. Notice that the additional information does not display. The alternative text for the image provides the content displayed using the onmouseover event handler. This allows users who know how to access this alternative text to get the content, but is not a truly universal solution.

Problems

In this example, additional content is being displayed using onMouseOver. This content can only be viewed if the user uses a mouse to hover over the image. It is not available to someone who is using the keyboard to navigate through the page. The onMouseOver event handler cannot be made directly accessible to keyboard users. Thus, an alternative must be provided.

Partial Solution

Place the additional content in the alternative text of the image itself. This would work for screen reader users - the screen reader would read the alternative text. But for sighted users whose browser does not display alternative text for images or who do not know to mouse over the image to see the alternative text, this is not a viable alternative. Still, the image must have equivalent alternative text.

Solutions

In addition to onMouseOver and onMouseOut, use onFocus and onBlur. These actions will be triggered when the keyboard is used to navigate to and from a link that surrounds the <img> element.

<a href="page.htm" onmouseover="document.images['myimage'].src='imageon.gif';" onfocus="document.images['myimage'].src='imageon.gif';" onmouseout="document.images['myimage'].src='imageoff.gif';" onblur="document.images['myimage'].src = 'imageoff.gif';"> <img src="imageoff.gif" width="289" height="79" id="myimage" alt="Accessibility - The quality of being accessible, or of admitting approach; receptibility." /></a>

You must still provide the descriptive alternative text for non-visual users, but onFocus and onBlur will provide the visual image swap for users that are using a keyboard only.

Example 2

A common use of onMouseOver and onMouseOut is for fly-out or drop-down navigation systems. Place your mouse over the menu items below to view an example of drop-down menus. When the mouse is placed over the main menu items (onMouseOver), additional sub-menu items appear below. When the mouse is removed from the menu system (onMouseOut), then the sub-menus disappear.

Products

Services

Support

Problems

Additional content and functionality is being displayed using onMouseOver. In this example, JavaScript is controlling the display of Cascading Style Sheet elements within the page. The sub-menu items will only be visible if the mouse is placed over the main menu item. These items may not be available if JavaScript is disabled and may not be read by assistive technologies.

Solutions

When possible, use additional event handlers that allow keyboard navigation. When this is not possible, you must provide redundant navigation. This can be done one of two ways. First, provide links within the main content of the page to the pages displayed in the sub-menu navigation. This is often done as a list of categorized links at the bottom of the page. The downside of this approach is that the navigation is only accessible at the bottom of the page, which might be counter-intuitive to most users.
A second method of providing the redundant navigation is to add a standard href link from each main navigation items (e.g., Product, Services, etc.) to a separate web page that contains the sub-menu navigation items. If you select the Products, Services, or Support links above you will see an example of providing redundant navigation.

Example

<a href="productlinks.htm" onmouseover="SlideOutMenu();" onmouseout="SlideInMenu();">Products</a>

While this method does require the creation of an additional page and introduces an additional step, it also provides full access to the navigation elements in an intuitive way. This method also allows the sub-menu items to be accessible if JavaScript is disabled.

onFocus and onBlur

These event handlers are typically used with form elements, such as text fields, radio buttons, and submit buttons. onFocus is triggered when the cursor is placed on or within a specific form element. onBlur is triggered when the cursor leaves a form element.
Both of these event handlers are device independent, meaning that they can be performed with the mouse, keyboard, or other assistive technology. The actions that are performed as a result of these event handlers must be analyzed to determine if they cause accessibility problems. Typically, these events do not cause accessibility issues unless they are modifying the default behavior of the web browser or are interfering with keyboard navigation within the web page.

Example 1

Place your cursor within the following textbox to see an example of the onFocus event handler.
Enter your name :

<input id="fname" type="text" onfocus="alert('Enter your first name only');" />

Problems

None. Although the alert window may be distracting and unnecessary, it does not introduce any serious accessibility issues. The alert is triggered when the text box gains focus, either by using the keyboard or mouse. JavaScript alerts are read by most modern screen readers and can be used to increase the usability of forms by providing timely feedback, instructions, or cues. However, if JavaScript is disabled, then the alert will not be available at all.

Example 2

In this example, the onBlur event triggers JavaScript code that changes the functionality of the Web browser. Place your mouse into the following text box and enter a number between 1 and 10. Then press the Tab key or click the mouse outside of the text box to trigger the onBlur event which will validate the number you entered to ensure it is correct and present feedback regarding your answer. If it is incorrect, the text box will retain the cursor focus until you enter the correct number. In this example, you MUST enter the correct answer of '6' to allow the browser to navigate to other portions of the page.
Guess a number between 1 and 10?
Enter Answer:

<input type="text" id="input1" size="5" onblur="checkAnswer();">

Problems

Although the onblur event is device independent, it is being used to execute JavaScript code that makes the page difficult to navigate. The textbox maintains focus until the correct answer is given. This change in browser default behavior may be confusing and restricting. Also, the feedback is displayed in a different part of the page. Because focus is maintained within the text box, a screen reader will not be able to access the feedback text or any other part of the page until the correct answer is entered.

Solution

Do not force the focus to remain within the text box. Allow the user to navigate throughout the page. Display the feedback on another page after the form has been submitted (works without JavaScript) or display the feedback with a JavaScript alert (requires JavaScript). Try entering a letter into the textbox above to see a JavaScript alert feedback message.

onClick and onDblClick

The onClick event handler is triggered when the mouse is pressed when over an HTML element. onClick is intended to be a mouse dependent event handler. However, if the onClick event handler is used with hypertext links or form controls, then most major browsers and assistive technologies trigger onClick if the Enter key is pressed when the link or control has focus. In these cases, onClick is a device independent event handler. Nevertheless, the Enter key will not trigger the onClick event if it is used with non-link and non-control elements, such as plain text or table cells.
The onDblClick event handler is associated with the double click of a mouse on a selected HTML element. There is no device independent or keyboard equivalent to onDblClick, which should be avoided.

Example 1

The following link triggers a JavaScript confirmation box which allows you to confirm whether you want to view the page or not.
View this onClick example

<a href="page.htm" onclick="return confirm('Are you sure you want to view this page?');">View this onClick example</a>

Problems

None. The confirmation box is read by all major screen readers. By using the return JavaScript parameter, the link action is cancelled if the user selects No in the confirmation dialog box. If JavaScript is disabled, the link will work normally.

Example 2

The following text is styled to appear like a link (blue and underlined), but is plain text that has an onClick event which opens another document in the browser window. Use the mouse to click the following text.

View another onClick example

<p style="color:blue; text-decoration:underline" onclick="location.href='page.htm'">View another onClick example</p>

Problems

Because the text is not a hypertext link or form control, it does not receive focus while navigating with the keyboard. Because it does not gain focus, the keyboard cannot be used to activate the onClick event.

Solution

Use the onClick event handler on a link or form control instead of an element that cannot be accessed using a keyboard.

Example 3

A very common use of JavaScript is to validate form information. The following form will use JavaScript to allow you to confirm the information you have entered.
Enter your name in the following box, then press the Submit button.

Name:

<form action="page.htm" onsubmit="validate(); return false;">
<p><label for="yourname">Name:</label><input type="text" id="yourname" />
<input type="button" value="Submit" onclick="validate();" /></p>
</form>

Problems

The confirmation and alert dialog boxes that are triggered by the onClick event are accessible to browsers and assistive technologies that have JavaScript enabled. Validating the form information with a server side script and then displaying feedback on another web page allows you to bypass any problems that may occur in the JavaScript code and allows the form to validate if JavaScript is disabled. If JavaScript is used to validate the form, make sure that all form elements and functionality can be completed using the keyboard. Because the onClick handler is used with a form element, it is activated using both the mouse and the keyboard.

Note
Because most browsers will submit the form when the Enter key is pressed, the onsubmit event handler has been added to the <form> tag to ensure that the form will validate if the user does not activate the Submit button, but presses the Enter key while focus is in the text box. Also notice the required form label for the text box.

Example 4

This example also validates the form information, but feedback is displayed in another place within the page.
How many items are in a dozen? Enter the amount into the box below, then press the Check button.

Enter Answer:

<form action="page.htm" onsubmit="checkAnswer2(); return false;">
<p class="invis" id="answercorrect">Correct, there are 12 items in a dozen.</p>
<p class="invis" id="answerwrong">Incorrect. There are 12 items in a dozen.</p>
<p><label for="answerbox">Enter Answer:</label>
<input type="text" id="answerbox" />
<input type="submit" onclick="checkAnswer2()" value="Check" />
</p>
</form>

Problems

The feedback is not presented in a manner that would be accessible to some assistive technologies. In this example, JavaScript is modifying the display style parameters for elements within the page to make them visible or invisible based upon the response. The screen reader user would not be aware that additional content has suddenly appeared within the page.

Solutions

1. Validate the form information with a server side script, then display the feedback on another page.
2. Provide the feedback in a way that is accessible, such as a JavaScript alert or another form element.

onChange and onSelect

The onChange event handler is triggered when a form element is selected and changed (for example, when a radio button is initially selected or when the text changes within a text box). The onSelect event handler is processed when text is selected within a text field or text area. Although these event handlers are device independent and can be activated using the mouse, keyboard, or other device, the actions that are performed as a result of these event handlers must be analyzed to determine if they cause accessibility problems.

onChange example

The following drop-down menu form element is used for navigation. By selecting an item from the list, JavaScript will automatically open the specified page within the browser.

Note
In some browsers you may have to hit the Enter key or click on the page after selecting a menu item to activate the onchange event handler. Click on the Back button in the browser to return to this page.

Go to:

<script type="text/javascript">
<!--
function goto_URL(object) {
window.location.href = object.options[object.selectedIndex].value; }
//-->
</script>

<form action="page.htm" onsubmit="return false;">
<p><label for="selectPage">Go to:</label>
<select name="selectName" onchange="goto_URL(this.form.selectName)">
<option value="">Select a page:</option>
<option value="page.htm">Page 1</option>
<option value="page.htm">Page 2</option>
<option value="page.htm">Page 3</option>
</select></p>
</form>

Problems

The JavaScript causes the browser to go to a new page using onChange or when the user selects an item from the select list. If the end user is using a keyboard, the onChange event handler is executed for every item within the list. It is impossible for the user to directly select the last item in the list, as each previous item within the list will trigger the page change. The only way the user can select the last menu item is by navigating to the page for the first item in the list, then pressing the Back button, navigating to the second item, then pressing the Back button, and so forth until the last menu item is accessed.

Solutions

Rather than using the onChange event handler, allow the user to select the item from a list then select a button or submit the form to activate the script. When server-side scripting is used to process the form information and redirect the browser accordingly, there is no need for JavaScript at all. The following code demonstrates one method of fixing the onChange problem.
Select a page using the drop-down menu then select the Go! button. Click on the Back button in the browser to return to this page.

Go to:

<form action="page.htm" onsubmit="return false;">
<p><label for="selectPage2">Go to:</label>
<select name="selectPage2" id="selectPage2">
<option value="">Select a page:</option>
<option value="page.htm">Page 1</option>
<option value="page.htm">Page 2</option>
<option value="page.htm">Page 3</option>
</select>
<input type="button" value="Go!" onclick="goto_URL(this.form.selectPage2);" />
</p>
</form>


Using Device Independent Event Handlers

As mentioned previously, several event handlers are device independent, including onFocus, onBlur, onSelect, onChange, and onClick (when onClick is used with link or form elements). When possible, use device independent event handlers. Other event handlers are device dependent, meaning that they rely wholly upon a certain type of input. For instance, onMouseOver, onMouseOut, and onDblClick rely upon the use of a mouse. There are also some event handlers that are dependent upon use of the keyboard (onKeyDown, onKeyUp, etc.). Multiple device dependent event handlers can be used together to allow both mouse and keyboard activation of JavaScript. For instance, both onMouseOver and onFocus (as well as onMouseOut and onBlur) can be used to provide both keyboard and mouse activation of a script. Using multiple device dependent event handlers together as a method of implementing device independence requires a great deal of testing across different browsers and assistive technologies to ensure that accessibility is not limited in any way.

Dynamic HTML and Accessibility

Dynamic HTML (DHTML) is typically a combination of Cascading Style Sheets (CSS) and JavaScript. DHTML allows developers to display, hide, or move information based upon input from the user or pre-programmed commands. Many of the examples in this section have used DHTML. Most drop-down or fly-out menu systems found on Web pages also use DHTML. Because most of these DHTML elements are modified based upon mouse input, they are typically inaccessible to users who do not use a mouse. When DHTML is used, two items must be evaluated to determine its impact on accessibility:

1. Is the event used to trigger a change device independent? If the mouse is required, then it is not fully accessible.
2. Is the DHTML content or functionality itself accessible? If assistive technologies cannot adequately access DHTML triggered content or functionality, then it is not fully accessible.

Using document.write

Dynamic, constantly changing information is being written to the page in this example using the document.write command in JavaScript. In most cases, content that is written to the page using JavaScript is accessible to assistive technologies. However, if the dynamic content is constantly changing or otherwise interferes with navigation or browser functionality, then it may cause accessibility problems.

document.write example

The current time is displayed in the text box below. It updates and changes every second.

The current time is:

Problems

In this case, because the content is constantly changing and refreshing, a screen reader would not be able to read it and it may cause some confusion.

Solutions

When using dynamic information, you must first ask yourself if it is necessary and vital to the function or content of the page. If so, there is often a way to provide the content without using inaccessible JavaScript. For instance, you could write the current time to the page when it loads using a server-side script. Though it will not be constantly updating, it may suffice. You may also have the user select a link or button to go to another page that displays the current time from server side processing. Another approach that uses a more accessible implementation of JavaScript would be to provide a link or button that allows the user to display the current time at their request.

<input type="button"
value="Display the current time"
onclick="alert('The current time is ' + timeValue);" />

Pop-up Windows

Pop-up windows provide a unique accessibility problem. First of all, most usability experts would argue against the use of pop-up windows except in the most extreme of cases. If you must use pop-up windows, know that they introduce several very unique accessibility issues. For a visual user, it may be difficult to notice and navigate to the new window. For someone who is using assistive technologies, the new window may be annoying and confusing because the default behavior for the link has been modified. JavaScript implementation may make the new window difficult or impossible to resize or scale for someone using a screen enlarger. For someone who is blind, there is typically no indication that they are presently navigating in a new window. When the screen reader user attempts to return to the previous page by selecting the back button, it may be confusing to find that this does not work.

Pop-up example

Select this link to open a new window

<a href="popup.htm"
onclick="window.open(this.href); return false;">Select this...</a>

Note
If you are using software to block pop-up windows, you may need disable the software or select the link in a way that bypasses the pop-up blocker (typically Ctrl + click or Ctrl + Enter with the link selected).

In the example code above, the link will continue to work normally (i.e., in the same browser window) if JavaScript is disabled.
When using JavaScript to open new windows, you can modify the size and position of the new window. You can also add or remove functionality of the window, such as the ability to resize, display scroll bars, show tool bars, etc. Be very careful when changing the default behavior of the browser window. If a user has low vision and must enlarge the content, a small window that cannot be enlarged and does not display scroll bars would be very inaccessible. Someone with a motor disability may rely upon large tool bars to accurately control the web browser, so removing or modifying them may introduce difficulties for this user.
As you can see, there are many difficulties in both usability and accessibility that arise through the use of pop-up windows. Care must be taken in making the decision to use them. If they are used, thorough user testing of your implementation is vital to ensure accessibility. Always alert the user to the fact that a pop-up window will be opened.

Redirecting and Refreshing Browser Windows

When the page the browser is viewing suddenly changes or refreshes, the person viewing that page may become disoriented or confused, especially if that person is using an assistive technology. This is commonly done with page redirects when page content has been moved or updated. Section 508 requires that users be given control over time sensitive content changes. Do not automatically change or refresh the browser window without first alerting the user that the change will occur and giving him/her the ability to disable or postpone the change.

Using Pure CSS as a JavaScript Alternative

As mentioned previously, Cascading Style Sheet (CSS) parameters are often modified using JavaScript to create dynamically changing DHTML pages. However, with the advent of CSS version 2, much of the dynamic functionality available with JavaScript is now contained within the specifications for CSS itself. This allows the construction of interactive and dynamic navigation and layout elements without the need for JavaScript events. You can create drop-down menus, interactive images, and other exciting features in Web sites without worrying about device dependent event handlers. However, the new CSS standards are not fully supported in modern browsers, namely Internet Explorer.
Also, screen readers do not have great CSS support, especially when presented with content that can be made visible or invisible using either the display:none or visibility:hidden styles. Many screen readers do not read content that is assigned these styles even though the content is still part of the underlying structure of the page. Until there is better CSS support in both web browsers and assistive technologies, using CSS alone to produce dynamic content should only employed with much testing in a variety of browsers and screen readers.

Introduction

Whenever JavaScript cannot be made directly accessible, an accessible alternative must be provided. Also, many user agents, such as web-enabled cell phones and PDA's, do not yet utilize JavaScript. There are several ways you can provide accessible alternatives when the scripting cannot be made accessible or when the end user does not have JavaScript enabled.

Server-side Processing

In many cases, the functionality provided by JavaScript can be duplicated by server-side scripting. For example, JavaScript is often used to validate form elements before a form is posted. Instead of implementing such JavaScript programming and its accompanying accessibility techniques, you could use a server-side script to validate the form elements. JavaScript is often used to write dynamic information to a web page, such as the current date and/or time. Again, using a server script or server-side include negates the need for additional accessibility implementation.

Using the <noscript> Element

Making JavaScript natively accessible is very important. However, in some cases, the end user may not have JavaScript enabled or may be using technologies that do not support JavaScript (e.g., cell phone, PDA, etc.). In such cases, you can provide non-JavaScript alternatives to user's who cannot or choose not to view JavaScript content.
When JavaScript is used within a Web page, the most straightforward way to provide an alternative for the JavaScript-generated content is to provide content within the <noscript> element. The <noscript> element can be used within your page to display content in browsers that do not support or have disabled JavaScript. However, if JavaScript IS enabled the <noscript> element is ignored.

Important
Providing an accessible alternative within the <noscript> element for an inaccessible script will not make the page accessible. The <noscript> content will only display if JavaScript is disabled. Most screen reader users have JavaScript enabled, and will thus encounter your inaccessible script and not the <noscript> content.

The <noscript> element provides alternative text for the JavaScript. If the content or functionality of the script needs an accessible alternative when JavaScript is disabled, then you need <noscript>. The <noscript> content should ideally contain the equivalent content or functionality that is provided by the script. However, this is often not possible. It is not sufficient to simply indicate, "Your browser does not support JavaScript." This does nothing to make the content accessible. You may, for example, provide a link to an accessible HTML alternative or to a page that utilizes server-side scripting instead. Or, at very least, describe the type of content that would be displayed if JavaScript were enabled.
<noscript> should be used anytime alternative or non-javascript content or functionality is required.

<script type="text/javascript">
<!-- document.write("The current time is " + currenttime) -->
</script>
<noscript>
<!-- link to page that displays time from server-side script -->
<a href="time.htm">View the current time</a>
</noscript>


<noscript> example

In the following example, two form buttons are provided within the HTML code. If you have JavaScript enabled, the document.write command within the <script> element will display the first button. If this button is selected, it triggers a JavaScript function that may be used to validate and submit the form using additional JavaScript within the page. If JavaScript is not enabled, then the button contained within the <noscript> element is displayed, which could submit the form to a server-side processing script, which would provide the form validation and feedback.

Username:

<script type="text/javascript">
<!--
document.write('<input type="button" value="Submit" onclick="validateForm();" />');
-->
</script>
<noscript>
<p>
<input type="submit" value="Submit">
</p>
</noscript>


Overview

JavaScript allows developers to add increased interaction, information processing, and control in web-based content. JavaScript can also cause accessibility problems by limiting navigation using a keyboard or assistive technology, presenting content or functionality that is not accessible to assistive technologies, limiting user control over automated content changes, and modifying the normal functionality of the browser. When faced with JavaScript accessibility issues, you must do one of the following:

• Ensure the JavaScript is directly accessible
• Provide an accessible, non-JavaScript alternative

JavaScript is often used to make cosmetic or other content changes that do not affect accessibility. Content written to the page using JavaScript is accessible if:

• Device independent event handlers are used.
• JavaScript enabled content and functionality is accessible to assistive technologies.
• Scripted pages and elements are navigable using a keyboard.
• The normal browser functionality is not modified in a way that may cause confusion or inaccessibility.
• An accessible alternative is provided when JavaScript cannot be made natively accessible.

JavaScript Event Handlers

There are two types of JavaScript event handlers - device dependent and device independent. When implementing event handlers, you must either use a device independent event handler or use multiple device dependent event handlers to accommodate all users. Below is a list of common event handlers and their associated accessibility issues.

onMouseOver and onMouseOut

Device dependent (require the use of a mouse)

Ensure important content or functionality is not introduced with these event handlers

Use in conjunction with the onFocus and onBlur event handlers to allow keyboard accessibility

Provide an accessible alternative if the content or functionality cannot be made natively accessible

onFocus and onBlur

Device independent (work with both keyboard and mouse)

Test to ensure that accessibility is not affected

onClick and onDblClick

Device dependent (require the use of a mouse)

onClick is activated by keyboard input when used with links and form elements

There are no device independent or keyboard accessible equivalents to these event handlers

Functionality and content provide by the onClick event handler must also be made accessible

onChange and onSelect

Device independent (work with both keyboard and mouse)

Functionality and content provide by the onChange and onSelect event handlers must also be made accessible

Drop-down menu navigation items that are triggered with onChange are not fully keyboard accessible

Dynamic HTML and Accessibility

Dynamic HTML (DHTML) is a combination of JavaScript and Cascading Style Sheets (CSS). By its very nature, DHTML can present dynamically changing content. DHTML is often triggered by user interactions, such as moving the mouse. When implementing DHTML, you must ensure that the DHTML is triggered in a device independent way and that the content and functionality provided by the DHTML is also accessible.
JavaScript can also be used to write dynamic content to the web page. In most cases, this content is accessible, unless the content is constantly changing or is in any other way interfering with accessibility of the page.

Pop-up Windows

The default behavior of the web browser and certain HTML elements can also be affected by JavaScript. Pop-up windows can be triggered by JavaScript or by JavaScript event handlers. If the user is not alerted to the fact that a pop-up window is opening, they may become confused or disoriented by the unnatural behavior of the Web browser. Further modification of browser windows to remove scroll bars, status bars, menu bars, or tool bars may also cause accessibility problems. Use pop-up windows with care and if they are used, always alert the user to this fact. The user must also be alerted when JavaScript is used to automatically perform browser functions, such as redirecting, refreshing, or automatic scrolling. In all cases, user testing and testing with assistive technologies can provide valuable feedback regarding accessibility of specific JavaScript implementations.

JavaScript Alternatives

There are many ways to provide alternatives to JavaScript. Newer versions of CSS allow much of the behavior of JavaScript to be replicated using CSS alone. Drop-down menus, navigation bars, and interactive images can all be developed without relying on JavaScript. However, the implementation of CSS across browsers and assistive technologies is varied and problematic. When JavaScript itself cannot be made natively accessible, you must provide an accessible alternative. This can be done by replicating or replacing the JavaScript behavior with server-side processing. You can also provide <noscript> content which will be accessible when JavaScript is disabled or not available to the end user.

Standards and Guidelines

The following standards and guidelines apply to JavaScript:

Section 508 of the Rehabilitation Act §1194.22:

• (l): When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
• (n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
• (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

W3C Web Content Accessibility Guidelines (WCAG) 1.0:

• 6.3 (Priority 1): Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
• 6.4 (Priority 2): For scripts and applets, ensure that event handlers are input device-independent.
• 6.5 (Priority 2): Ensure that dynamic content is accessible or provide an alternative presentation or page.
• 7.4 (Priority 2): Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.
• 7.5 (Priority 2): Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.
• 8.1 (Priority 2): Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
• 10.1 (Priority 2): Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

Getting Sourcey — native HTML5 Audio and video

Hard perhaps to believe, but the world wide web began without an image element. That’s right, there was no way to include images as part of the content of a web page before Mosaic implemented them (here’s Marc Andreesen proposing the img element at the beginning of 1993). The img element ushered in the age of included content so the web browsers could now display gif, jpeg, and more recently PNG format images in a standard way, but that’s where matters stayed for more than a decade. While the non-​​standard embed element (ironically, now standardized in HTML5, and later standardized object element enabled developers to include audio, video, and interactive content, browsers did not implement native handling of these kinds of media — the actual rendering was left to plugins, like Flash (while the number of different commonly used plugins today is quite low, in the late 1990s there was an explosion of different plug in technologies.)
While HTML5 for the first time specifies a way of incorporating audio and video content via the mundanely named audio and video elements, the revolution in web content these bring is that browsers now no longer require plugins to play the content, rather they do so “natively”. Which has the advantage that users don’t need to download and install plugins, or keep them up to date. But there’s more to it than that. With plugin content, browsers effectively hand over a part of the browser window and say to the plugin — “ok, this is all yours, do your worst”. Which makes applying style to a video player (rounded corners, or adding a drop shadow, for instance) challenging, and effects like layering HTML based content over the top of plugin content a bit of a lottery.
HTML5 audio and video has been, in browser years, quickly adopted by all major browsers (we’ll cover off browser support in just a moment). But let’s first take a look at how we incorporate audio and video content into HTML5 documents, how to provide fallbacks for browsers which don’t support them, and the inevitable gotchas. And once again, I’ll introduce a couple of tools we’ve developed to make life easier for you when using native multimedia content in your web sites and applications.
There are a lot of great resources out there, which go into much more detail on some aspects we only really touch on here, particularly on the complex issue of formats and codecs, as well as the challenges of making your content accessible. There’s a list of further reading at the end of the article.
We’ll begin by looking at audio, and then follow up with video, which we use in almost exactly the same way as audio.

HTML5 Audio

HTML5 introduces the audio element, for embedding audio files in a page. Browsers which support HTML5 audio provide a simple audio player for playing, scrubbing forward and back through content, as well as setting the volume. It’s also possible to hide these controls, and either autoplay files, or build your own player interface using HTML and the audio element’s JavaScript API (which is beyond the scope of this article, but not really that difficult at all if you are competent in JavaScript).

Setting up the element

The first thing we need to do to include audio in a page is to add an audio element to the HTML. Unlike img, audio is a non empty element — that is it can contain other HTML, so has an opening and closing tag.

<audio></audio>

Of course, this isn’t going to play anything, just as an img element with no src attribute won’t display an image. So, you’re probably guessing we add the audio file reference using a src attribute. And you’re more or less right. We can do that, but there is another, better way to add a reference to the sound files we want to play. This is because the audio element can have only one src attribute, but because different browsers support different audio formats, at least for now, and for the foreseeable future, we’ll need to provide browsers with multiple sound files, so that we cover all browser bases. We’ll turn to how we do this in a moment, but let’s first look at several other attributes the audio element can take.

controls

The controls attribute, when present, tells a browser to display the default controls for its audio player. If the attribute is not present, then no controls will be displayed.

loop

another boolean attribute, if this is present, the audio file will begin again after it has played indefinitely

autoplay

if this attribute is present, then once the sound file can begin playing, it will. autoplay should be used carefully and sparingly!

autobuffer

this is now replaced with the preload attribute which we’ll look at in a moment, but as older browsers, for example Safari 4 support autobuffer instead of preload, you may wish to add this attribute as well if you want audio to be buffered by the browser as soon as a page is loaded. Browsers may choose to ignore this, or not support it at all (Opera for example doesn’t support preloading of audio)

Before we continue, these attributes are boolean attributes, which you might not necessarily be as familiar with as you are regular attributes. Boolean attributes (another exampled is checked) are either true, or false, depending on whether they are present or absent on an element. So, they look like this

<audio controls loop></audio>

That is, they don’t take values. If this offends your XHTML sensibilities, they can also be written like so

<audio controls="controls" loop="loop"></audio>

That is, with their name as their value as well. Why they aren’t written as controls=“true” is beyond me, but there you have it.
In addition to these boolean attributes, and the src attribute (which we’ve recommended ignoring) audio can also take the preload attribute, which has one of three values. The preload attribute doesn’t force the browser to preload an audio file, but rather, suggests to the browser how it can provide the best user experience to the user (balancing the impact of downloading a potentially large file, with the benefit of faster response to their choosing to play a file). In the words of the specification, these values are

none

Hints to the user agent that either the author does not expect the user to need the media resource, or that the server wants to minimise unnecessary traffic.

metadata

Hints to the user agent that the author does not expect the user to need the media resource, but that fetching the resource metadata (dimensions, first frame, track list, duration, etc) is reasonable.

auto

Hints to the user agent that the user agent can put the user’s needs first without risk to the server, up to and including optimistically downloading the entire resource.

Getting Sourcey

Having suggested we don’t use the src attribute to link to the audio file to be played, how then can we do this? Well, we saw audio elements can contain other HTML elements, and in this case, we’re going to use the source element (also new in HTML5), to provide links to one or more audio files in various formats. The browser can then download the format it supports, ignoring others to save bandwidth.
Like img, the source element uses the src attribute to link to a file. So, if we want to link to an mp3 file, we do so like this

<source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">

and, if we put that all together, that’s all we need to play this file in browsers which support mp3 (at present, IE9, Safari, Chrome, Android and iOS).

<audio controls="controls" loop="loop">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">
</audio>

While several browsers will be able to play this content, neither Firefox nor Opera support the mp3 format natively. They both however, support the Ogg Vorbis format, so in addition, we’ll link to an ogg version of this same audio file, for the benefit of users of these browsers.

<audio controls="controls" loop="loop">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.ogg">
</audio>

Where a browser happens to support both ogg and mp3, it will use the first source it finds which it supports, and so in this case, play the mp3 version.
So now we have an audio element, with two sources, which provide audio that can be played in all modern browsers. But what about older browsers? Can we also include support for them? Let’s find out.
As an aside, beneath the seemingly simple issue of audio and video formats, there’s more than a little complexity. We’ll look at this whole issue separately in the gotchas section, but I’ll just note here, that we can give the browser further information about the file, including it’s MIME type, and a specific codec to be used to decode it using the type attribute. This can further help a browser in deciding whether to download a file — audio and video files are typically large, so browsers really should only download files they can very likely play. For now, just note we have the type attribute, which may be useful, for example, to distinguish between audio files of the same format encoded at different bitrates.

Providing fallbacks

Because we’ve long been able to embed audio and video in a web page using Flash (or Silverlight, and other audio playing plugin technologies), we can use this to provide a fallback player for audio content. There’s two approaches to this (for simplicity, we’ll only consider the case of Flash, but a similar approach can be used with Silverlight).

1. We use the object element to link to a .swf version of our audio file, which Flash can play
2. We use object to embed a Flash audio player which can play mp3 files

The first approach is simplest, but Flash won’t display controls for the sound file — the user will have to context menu click to play, rewind, etc.
The second approach potentially involves hosting an audio player at your site, or using a free hosted player such as the Google Reader Audio Player, but has the advantage of reducing the number of audio files we need to encode, and of providing a better user experience.
In both cases, we use the object element, as the only browser we really need to worry about is Internet Explorer versions 8 and older, which support object. Unless you’re looking to also cover an old version of a browser that doesn’t support object (which to be honest is unlikely), there’s no need to also include a nested embed element inside the object.
Here’s how we go about using the object element to add the Google Reader player, and our sound file.

<object type="application/x-shockwave-flash" data="http://www.google.com/reader/ui/3523697345-audio-player.swf" width="400" height="27" >
        <param name="flashvars" value="audioUrl=http://westciv.com/podcasts/youmayknowmypoetry.mp3">
        <param name="src" value="http://www.google.com/reader/ui/3523697345-audio-player.swf"/>
        <param name="quality" value="best"/>
</object>

There’s no great need to go into detail here, because all you really need to know is the value of the flashvars parameter includes the URL of the sound file. Simply replace the URL there, leaving the audioURL= part as is, and you’ll be fine.
Note that this fallback won’t work if the browser supports audio, but none of the audio formats you’ve linked to, or if the files go missing. The browser in these instances will show the native audio player controls (if you’ve used the controls attribute), but no sound will be played.
Lastly, what if we have a browser that supports neither audio, nor the object element? We can include fallback text (and HTML) within the object element (or if we choose not to include a flash based fallback, inside the audio element, after any source elements). We could for example link to a downloadable version of the file. Here’s what this would look like if we haven’t included a Flash based fallback

<audio controls="controls" loop="loop">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.ogg">

 <p>Sadly your browser can't play this audio file</p>
 <p>The good news is you can still <a href="http://westciv.com/podcasts/youmayknowmypoetry.mp">download an MP3 version</a></p>
</audio>

Gotchas

We’ve covered most of the things that can trip you up with audio (with the exception of the whole issue of formats and codecs which we’ll cover shortly) but keep in mind these as well:

• fallbacks only come into play if the audio element is not supported, not if the file formats aren’t or if the files are missing.
• ogg files must be served as audio/​ogg or application/​ogg. If the server is set up to serve these as another MIME type, Firefox will ignore them.
• Fallback text is not for the purposes of accessibility, but as a last resort when audio is not supported (we’ll look at accessibility in a moment).

But, on the whole, HTML5 audio is not particularly complicated, and in my opinion far less of a headache than using plugin based audio with the object and embed elements. As I mentioned earlier, I’ve built a web based tool that helps you create audio elements, including fallbacks, and hopefully helps you understand exactly what’s going on. Let me know what you think

HTML5 Video

Let’s now turn to incorporating video in HTML5 documents, and the good news is, it’s more or less identical to audio. Where audio and video are the same, we won’t repeat what we’ve covered earlier.

Adding the element

In place of the audio element, for video we have, not surprisingly, the video element. As with audio, we recommend you don’t use the src attribute to link to the video file, but again the source element, so we can link to different formats (as with audio, different browsers support different formats, so to cover all modern browsers we need at least two different video files).
video elements can take all the attributes of the audio element — controls, loop, autoplay and preload. But in addition, it can also take the poster attribute. The value of the poster is a url that specifies a file to be used as a placeholder image when video is not playing. Here’s a video element, with controls, and a poster

<video controls="controls" poster="http://westciv.com/podcasts/lesson6.jpg">
</video>

and while this won’t play any video, it will look impressive, something like this

Adding sources

Now we need to specify the video files to be played. As with audio, we use the source element, with the src attribute pointing to the video file to be played. To cover modern browsers, we need at least two formats, to simplify considerably, h.264 and either ogg/​theora or webM/​VP8.

<video controls="controls" poster="http://westciv.com/podcasts/lesson6.jpg">
 <source src="http://westciv.com/podcasts/lesson6.mp4">
 <source src="http://westciv.com/podcasts/lesson6.ogv">
</video>

Which now gives us video which will play in almost any modern browser, including IE9. again, we’re going to add fallbacks much as we did for audio, to round out our coverage.

Providing fallbacks

The simplest way to add Flash based fallback video content is to create a .swf version of the file, and then embed this in your HTML document using the object element. If Flash is installed this will play in the user’s browser, and while no controls will be shown, if you add a menu parameter with the value of true, then the user can context menu click and play, rewind and otherwise control the video.

<object type="application/x-shockwave-flash" data="http://westciv.com/podcasts/lesson6.swf" width="320" height="400">
    <param name="movie" value="http://westciv.com/podcasts/lesson6.swf">
    <param name="menu" value="true">
  </object>

All we need to concern ourselves with here is that we put the url of our video file as the value of the parameter with the name “movie”, as well as the data attribute of the object element.
There are also various Flash based video players we might include, similarly to the way we included the Google Reader MP3 player. This will likely require serving the Flash application, in addition to the video files.
Again we’ve used only the object element, as we’re really only looking to ensure IE 8 and older is served the video, and as these support object there’s no need to also include the embed element.
Lastly, as with audio, we can provide fallback text or HTML to display when video is not supported. Here, we’ll provide a download link when neither video nor Flash are supported.

<video controls="controls" poster="http://westciv.com/podcasts/lesson6.jpg">
 <source src="http://westciv.com/podcasts/lesson6.mp4">
 <source src="http://westciv.com/podcasts/lesson6.ogv">

 <object type="application/x-shockwave-flash" data="http://westciv.com/podcasts/lesson6.swf" width="320" height="400">
  <param name="movie" value="http://westciv.com/podcasts/lesson6.swf">
  <param name="menu" value="true">

  <p>Sadly your browser can't play this video file</p>
  <p>The good news is you can still <a href="http://westciv.com/podcasts/lesson6.mp4">download an MP4 version</a></p>

   </object>

</video>

Gotchas

HTML5 video gotchas are similar to those with audio. Fallbacks are only for when video is not supported at all. Ensure video files are served with the right MIME type. But on the whole, both audio and video are quite usable today.
As I’ve mentioned, the single biggest challenge is ensuring we serve the right video files, to ensure all browsers can play the video. Which means delving a little into the more complex issue of formats and encodings.

Video and Audio formats

Probably I should skip this part, and just point you in the direction of Mark Pilgrim’s fantastic coverage at Dive Into HTML5. But, I feel I should at least cover this issue briefly, so here goes.
When we think of video formats, like h.264, there are in fact 2 and usually 3 separate pieces of technology involved.

• There’s the container file — for example MPEG4, WebM or Ogg
• There’s the video data, encoded with one of many possible codecs (decoding/​encoding formats) such as H.264, VP8 or Theora
• There’s audio data encoded with one of many possible audio codecs such as mp3, AAC or Vorbis

So, when we talk about the video format a browser supports, it’s important to understand what this actually means. It means the combination of container, video and audio encoding.
With this in mind, The current state of browser support for audio and video formats is

Video

• Firefox 3.6+, Chrome, Android 2.1+ and Opera support Ogg/​Theora (.ogv).
• IE9, Safari 4+, Chrome, Android and iOS support MPEG4/h.264 (.mp4), although Chrome 14 will drop support for the format.
• Firefox 4+, Chrome, Opera, and Android (2.3+) support WebM/​VP8 (.webm), as does IE9 if the required codecs are installed on the system (they can be downloaded from here)

So, to cover all modern browsers, we need at a minimum, MPEG4/h.264 and either Ogg/​Theora or WebM/​VP8

Audio

• Firefox, Chrome, Android and Opera support Ogg/​Vorbis (.ogg).
• IE9, Safari, Chrome, Android and iOS support MP3 (.mp3).
• Safari, Chrome, IE and iOS support AAC (.aac).

To cover all modern browsers, we need Ogg/​Vorbis and either MP3 or AAC.

The type attribute

We mentioned earlier that the source element can take a type attribute in addition to the src attribute. While not required, this can help a browser decide whether it can actually play the content located at the end of the src URL. You might think that the file extension would be enough, but not necessarily so. For example, iPhone with iOS 4 supports H.264 video up to 720p (the so called H.264 “Main Profile”), so can’t play a 1020p H.264 encoded video (that is, a “High Profile” H.264 video). If we wanted to provide various H.264 profiles, for various devices, all these files will have the extension mp4. But we can provide codec information in the type attribute to differentiate between the various versions.
The type attribute’s value provides two pieces of information, separated by a semicolon. First is the MIME type of the file, then (optionally) the codecs used (separated by a comma). So, for example we could provide various H.264 profiles of our video like so:

<source src='video.mp4' type='video/mp4; codecs="avc1.58A01E, mp4a.40.2"'> <!-baseline profile-->
<source src='video.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'>
<!-main profile-->
<source src='video.mp4' type='video/mp4; codecs="avc1.64001E, mp4a.40.2"'> <!-high profile-->

(Which to tell the truth is taken directly from the HTML5 specification, and is beyond my level of understanding of the ins and outs of codecs.), but depending on your circumstances, you may find it useful to include MIME type and codecs information using the type attribute. If you do, I’m sure you’ll know the codecs information to use, and now where to put it.

Accessibility

The web is about inclusivity and access to as wide an audience as possible, which includes those with hearing and visual disabilities. Creating accessible audio and video content is far beyond the scope of this article, but I do have some links for further reading below. But, it is important to note that, as spelt out in the HTML5 specification

In particular, [fallback] content is not intended to address accessibility concerns. To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/​or to embed accessibility aids (such as caption or subtitle tracks, audio description tracks, or sign-​​language overlays) into their media streams.

The tools

I’m not sure whether it’s stupidity, or laziness, but many aspects of web development, if I’ve not used a particular technology for a while, I quickly find myself reaching for a reference. And sadder still, it’s often the book I wrote myself! But in all seriousness, as aspects of CSS and HTML (not to mention JavaScript and the DOM) become increasingly complex, our chances of remembering every aspect of our craft, along with the subtleties of browser support, grow ever smaller (even Einstein was reputed to have said that he didn’t remember the speed of light as he could always look it up). Well, mine certainly do. So, I write little web based tools to replace my dwindling brain cells.
I’ve recently developed two new tools, one each for audio and video, that help you easily do pretty much all we’ve covered here — create the elements, add controls, a poster, and other attributes, sources, and fallback audio, video and HTML. It will even tell you which browsers can play a particular file (well, it will make a guess based on the files’ extensions).
You can find the audio tool here, and the video tool here.
There’s also a similar excellent tool for creating HTML5 video which I wasn’t aware of when creating mine, the Video for Everybody Generator. It’s highly recommended.

Further reading

Here’s a few of the many articles and other resources on HTML5 video and audio I’ve come across in my travels. They cover video and audio encoding, accessibility, some Flash players you might consider for your fallback content, browser support, and more.
The very best place to start is the video chapter in Mark Pilgrim’s Dive into HTML5.
Video for Everybody, the originator of the Flash fallback technique for HTML5 Video
Opera Developer Connection has a series of articles on HTML5 media, including an Introduction to HTML5 Video, and Everything you need to know about HTML5 audio and video.
The HTML5 Doctor has a detailed overview of HTML5 Audio, and video.
HTML5 Rocks has several various articles on native HTML5 media including a quick guide to audio, the basics of HTML5 video

Encoding your audio and video

Here are some great places to get tips and techniques on encoding video and audio for HTML5, and services which you can use to create the right formats of your media files

• Encoding​.com has free and paid encoding services for many audio and video formats
• Here’s a detailed list of various encoding services
• ZenCoder is another hosted encoding service, with free service for testing, and various pricing options
• Vid​.ly is a service for encoding and hosting video

Flash players for video and audio fallback

There are some open source Flash video players you can host yourself to play your video files.

• FlowPlayer
• JW Player
• Media.js supports both audio and video with fallbacks to Flash
• VideoJS is a highly regarded JavaScript HTML5 player, with fallback support as well. You can skin it with CSS.
• JPlayer open source jQuery HTML5 Audio /​ Video Library (as used in Pandora)

In addition to the commonly used Google Reader Flash MP3 Player, other Flash MP3 players you might consider include

• The innovatively named MP3 Player
• And equally so Free Flash MP3 Player

Accessibility

• Captioning HTML5 Video using JavaScript from the Opera Developer Center
• Creating Accessible HTML5 YouTube Video

Browser support

As always When Can I Use? is the place to keep up to date with browser support.
Addressing challenges playing audio and video in the Android browser.
A look at the challenges associated with video on the iPad.
A further look at HTML5 media challenges in iOS.