Allowing users to interact with a Web page produced in recent years a significant increase in the use of client-side scripts: Javascript code can respond in real time and handle a variety of information. The Web2.0 is the ultimate expression of this capacity for interaction, in which the end user - the user-actively participates in the construction and all 'evolution of the Web site, interacting with it and helping yourself. Is referred to User-Generated Content (UGC or - user-generated content) that sees the "navigator" certainly not passive!

To achieve this interaction, then to allow the end user to add his contribution, have developed a series of techniques that have changed the appearance and behavior of Web pages (static so far, and now similar to traditional applications of Desktop) in recent years. Modify the contents of a page, send files, to give their vote to a video or document, register or modify your data, are just some of the operations requested in many services (2.0 beta) on the Web

The growing demand for client tools (Prototype, Dojo Toolkit, jQuery, ASP.NET Ajax, ...) and server (Ruby on Rails, PHP libraries, JSP and ASP, ...) for the development of Web 2.0 has led to the emergence of many development tools, libraries or simple philosophy of a new development on the Web;

These techniques and these instruments have been used in almost all possible combinations, thanks to their modular feature and the ability to solve certain tasks at specific times. Some have chosen, therefore, solutions entirely in Adobe Flash, who used hybrid solutions (Adobe Flash + Javascript), who, starting from generic libraries like Prototype, has achieved its specific Framework. The majority of these instruments is also open source (or free) and this has certainly contributed to a huge spread very quickly.

The price you pay, however, to get this new interaction has been a net loss of accessibility (and often usability) of the Web Paradoxically, the increased capabilities of interaction has restricted the number of users who, for various reasons, can not access these new technologies! There was, therefore, un'incremento the Digital Divide, often exclusively due to the abuse of some technical development or simply not taking account of some final target.

When you develop a Web site, or simply a Web page, do not forget the 'end user, who can visit our site with devices (browser or user agent) other than those that we expect, above all, with characteristics and settings other than those we have taken for granted (screen resolution, number of colors, JavaScript disabled, lack of Applet, or ActiveX Plugin, etc ...). It follows that in addition to mere compatibility (functional and visual) between different browser must pay attention to the characteristics they have. The argument, of course, is complex and articulated.

It is fair to force a user to have JavaScript available and enabled to navigate our Web site?

I think there are two possible answers to this question, the first may be no, not right, especially if what we want to achieve can be structured so as to allow both an advanced access is a basic access. However, and this is the second response, there are obviously borderline cases where the requirement to have a particular technology is independent of the ability - and willingness - analyst programmer!

Also - controversial - who are we (developers) to determine and compel those who should have what?

If the project we want to achieve is that they can be used by any user agent, with proper precautions, development time and the growing complexity of the code (HTML, JavaScript and Server Scripting) increases. It is a productive choice, personally, to dictate the rules of boot. However, the formal compatibility is not an operation that must be planned from the outset, we can indeed address the issue at a later time, when our Web site (or our service) is already online.

Normally we use two techniques, or two approaches, to build a truly accessible Web:

• Graceful Degradation
• Progressive Enhancement

Graceful Degradation

This technique, also used in fields other than web design, is assumed to concentrate now in the implementation of a Web site highly evolved, using techniques and technologies without worrying about compatibility issues at all, and accessibility. Usability, however, is - of course - the first ingredient for the definition. The second step is to incorporate all the features to support browsers and users who are - in fact - to the margins.

It will then use our tables to format the layout, not exacerbate the use of CSS and float, so as to respect the layout of the site even on older browsers. Javascript appears where you will use the Tag NOSCRIPT to provide an alternative access. Use the Tag ALT TITLE ALT TITLE where richest, etc ...

Graceful degradation has, however, limits. Do not take seriously into consideration the different types of user agents (or users) from the beginning, can have bad (sometimes ugly) consequences in the aftermath. Not always, in fact, you can add those Artefiz and tools can provide a real alternative content to different users. The experience of the analyst web developer / designer, in this case, plays a key role. However, a Web site evolves over time, it improves, adds features that may not be resolved in other ways, if not forcing the use of a particular technology: the vision of a video (in Flash, QuickTime or other) is difficult -- if not impossible - to achieve in standard HTML?

Progressive Enhancement

This approach is probably what personalmentre prefer. It is the exact opposite of Graceful Degradation. For those who enjoy the use of style sheets is a technique already known: from the basic structure, the simple markup, and as you add all the advanced features. Under the layout, then CSS is the approach used for the 'image replacement or substitution by style-sheet of text with an image (there are some other techniques that exploit even Ajax or even Flash).

Of great interest in this type of approach, is to spread the so-called Unobtrusive JavaScript: JavaScript that is not intrusive. This technique can improve the functionality of a Web site by exploiting the ability to manipulate the DOM JavaScript. By placing in a timely manner JavaScripts on the page you can do to make them transparent to the browsers that support JavaScript (or have disabled Javascript) but working for others.

The characteristics of a Unobtrusive JavaScript are:

• Improvements or changes - Not implemented - features already
• Transparency in the user agents that do not support or disable Javascript

Point 1 is essential for accessibility, in the same way 'used in the CSS image replacement. An example is Snap, which improves the visibility of a link. Snap is a classic example of a Unobtrusive JavaScript: JavaScript is disabled if the link is still present and functioning, however, if JavaScript is enabled preview functionality is added. Also if you can not access JavaScript no message is displayed: Point 2 - non-intrusive.

Another example of Unobtrusive JavaScript well made and Lightbox JS, which improves the slideshow of images. Starting from a series of links (Tag <A>) with the rel attribute set is able to properly display images linked in a really catchy!

This technique is extremely versatile and allows a true Progressive Enhancement approach - and, without exaggeration, a true web2.0 approach.

In this scenario the use of the library Prototype is easy access to the DOM HTML allows to override and add functionality to the elements of a page by making them more versatile.

Both techniques, therefore, allow to realize the end of Web sites truly accessible. Conversely require attention and additional work in the end is rewarded by a greater amount of visitors! I personally adopt the technique of Progressive Enhancement, for a purely subjective and habit. Choose between the two techniques can be indifferent to the experience, along with the type of project you must develop, certainly plays a key role.

As an example is worth a thousand words, I propose that before mosrtare some simple code extracts truly enlightened.

Related Post

• All Lightbox clones in a dynamic array (8)
• Shadowbox 3.0 beta (1)
• Light Library: Slimbox by a Shadowbox, galleries in Javascript (14)
• Light gallery: Lightview 2.0.0_rc1 (2)
• Web2.0: Gran Paradiso Firefox 3.0 and Apollo (2)

Was this article helpful?:

Loading ...