Accessibility in Web 2.0 technology

Summary: Accessibility has become a hot topic as increased awareness and growing requirements demand that applications take into account the needs of all potential users. Accessibility covers not only the Web application, but document, desktop application and hardware, and so on. In the Web application domain, making static Web pages accessible is relatively easy. But for Web 2.0 technology, dynamic content and fancy visual effects can make accessibility testing very difficult. This article introduces the WAI-ARIA standard, which is designed to make future Asynchronous JavaScript and XML (Ajax) widgets accessible. The article also covers accessibility principles in Web 2.0 design and provides several code samples to get you started.

According to WCAG 2.0, there are some common accessibility issues that are typically found in Web 2.0 applications. These issues can be categorized into four kinds of problems:

* Document structure
* Dynamic content updates
* Enhanced keyboard accessibility
* Widget accessibility

Within this article, we take a look at each of these problems and propose possible solutions.

The AT and Web pages relationship using WAI-ARIA

To Create Captcha Images using .net ( Cs File )

Onload Function
CaptchaImage ci = new CaptchaImage(this.Session["CaptchaImageText"].ToString(), 200, 50, "Century Schoolbook");

// Change the response headers to output a JPEG image.
this.Response.Clear();
this.Response.ContentType = "image/jpeg";

// Write the image to the response stream in JPEG format.
ci.Image.Save(this.Response.OutputStream, System.Drawing.Imaging.ImageFormat.Jpeg);
//imgCaptcha.ImageUrl = ci;
// Dispose of the CAPTCHA image object.
ci.Dispose();

MIDP Application Properties

A MIDlet, an application based on the Mobile Information Device Profile (MIDP), has access to two sets of runtime properties: system and application.


The concept of system properties is actually defined by the Connected Limited Device Configuration (CLDC), on which the MIDP is based. The underlying platform sets the properties and the application can obtain their values but cannot change them. The set of system properties varies depending on what features are available on the platform - see the FAQ "What are the defined J2ME system property names?" for a partial list of common system properties. To read a system property the MIDlet invokes System.getProperty(), a static method.


Application properties are obtained from the union of the attributes defined in the application descriptor and those in the MIDlet suite's manifest, part of the JAR file packaging. You set their values when you package the application for deployment. Consider a typical application descriptor:

MIDlet-1: HttpWrapperMidlet,,httpwrapper.HttpWrapperMIDlet
MIDlet-Jar-Size: 16315
MIDlet-Jar-URL: HttpWrapper.jar
MIDlet-Name: HttpWrapper
MIDlet-Vendor: Vendor
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0
Which-Locale: en



To read an application property like the Which-Locale attribute in this descriptor, a MIDlet invokes MIDlet.getAppProperty(), a non-static, instance method. This example code obtains the name of the MIDlet suite by querying the MIDlet-Name property:

import javax.microedition.midlet.*;

public class MyMIDlet extends MIDlet {
private String suiteName;

public MyMIDlet(){
suiteName = getAppProperty( "MIDlet-Name" );
... // more stuff
}

... // etc.
}



Property names are case-sensitive. If a property is not defined by either the application descriptor or the manifest, null is returned. If the same property is defined differently in the application descriptor and the manifest, the conflict is resolved in one of two ways: If the MIDlet is a trusted application based on MIDP 2.0, the system simply won't install the application. Otherwise, the value in the descriptor overrides the value in the manifest.


Application properties are particularly useful when descriptors are generated dynamically. For example, you can embed a registration key in the descriptor that the application will read and pass back to a registration server the first time it's run, without having to recompile or repackage the application itself. Don't stuff a lot of data in the descriptor, though, because some platforms limit the descriptor size. Use application properties wherever you'd use a standard Java properties file in a J2SE application.