Ne pas laisser tout le monde re

• Demo
• Agrandir
• Recharger
• New window

Purpose: The nature of the internet is that not everyone will receive JavaScript in the way intended. Therefore JavaScript should be applied in a way that enhances the page, rather than requiring it.

Use un-obtrusive JavaScript
Type: Maintenance, robustness, accessibility
The three pillars of web development are:

• Content and structure: HTML         <h1>Main heading</h1>
• Presentation: CSS             h1 {color: black}
• Behaviour: JavaScript         getElementsByTagName("h1")

The only required part of that triumvirate is HTML, which has the content and controls. Both CSS and JavaScript should in essence be enhancements.

An 'unobtrusive' script will:

• Not make assumptions about what methods browsers support.
• Check that the correct HTML is there to act upon, otherwise do nothing.
• Keep the functionality independent of the input device.
• Keep the scope of the script self contained.

For example, to create a show/hide area with this HTML:
<div id="container">
<h2>Heading</h2>
<p>Some text... </p>
</p>

The script could hide the text, wrap the heading content in a link, and attach an event to that link that shows the paragraph below.

If the script does not function, the text is shown. Just about any situation can be dealt with in this way, by planning for the scripts from the start, but implementing them at the end (i.e. building the back-end functionality as though there was no JavaScript available).

Once the back-end functionality is in place, layering on the behaviour (front-end scripts) can greatly enhance pages without requiring JavaScript. With this technique in place, you can also provide a mechanism to turn-off scripts where they are causing difficulties for people with partial JavaScript support.

Further reading:
http://dev.opera.com/articles/view/the-seven-rules-of-unobtrusive-javascrip/

Use standard HTML controls
Type: Accessibility, robustness
It must be possible for assistive technologies to identify the name, role, state and properties of all user interface components such as form elements, links and components generated by scripts. The easiest way to achieve this is to use standard HTML controls for web user interface components.

Accessibility guideline: WCAG 2 - 4.1.2

Use a library for complex scripts and cross-browser event-handling
Type: Robustness, maintenance
A JavaScript library will not take away the need for cross-browser testing, however, it will considerably reduce the time required to make a script cross-browser compatible. For short scripts with limited functionality a library is not needed, this requirement is aimed at sites with more extensive JavaScript functionality.

The exact library used is at the discretion of the developer, but it should support unobtrusive JavaScript.
Libraries can impact the download speed of a web site, however following these practices should minimise that impact:

• Make scripts external files, therefore cacheable.
• Put the scripts at the bottom of the HTML page, so that the page loads before the script.
• Minify the scripts (the library probably has a minified version already). http://crockford.com/javascript/jsmin
• Set the server to use Gzip for HTML/CSS/JavaScript files (not image or binary files).
• Use a library that is either small, or does not require a large initial download. (I.e. some libraries only call the components needed.)

Do not use onchange for navigation
Type: Accessibility
Using "onfocus" or "onchange" events to open a new page can cause a lot of confusion, so do not initiate a change of page or a pop-up with those events. This means that a menu using a select drop-down should have a 'go' button.

Accessibility guideline: WCAG 2 - 3.2.1, 3.2.2

Do not enforce timing in pages
Type: Accessibility
Given the different ways that people use pages, it is impossible to tell how long someone will take to get to a particular part of the page. Therefore any time limit set on a page will be too long for some people, and too short for others.

It is difficult to provide very specific guidance, but the principle is that there should be no time limits unless:

• The user can turn off the limit.
• The user can adjust the limit over a wide range.
• The user is given at least 20 seconds to extend the time limit with a simple action.
• The limit is needed for a real time event, such as an auction.
• The limit is greater than 20 hours.

For HTML and JavaScript, it can help to:

• Prevent session time outs: Provide a checkbox at the beginning of long forms that allow the user to specify a longer session time limit, or no limit with a logout link instead.
• Give the user control over scripts with time limits: Allow the user to turn off a time limit, set it at up to 10 times the original time, or to pause the time limit.

Accessibility guideline: WCAG 2 - 2.2.1

Avoid movement, blinking or updating pages
Purpose: Prevent distracting people with cognitive disabilities.
Movement in pages can be very distracting for many people, but particularly for people with learning difficulties, or conditions such as Dyslexia. Continuous movement can be distracting to the point that it becomes impossible for some people to carry out the task they have come to the website to accomplish.

Animation, moving areas of the page, or even video should not start automatically and continue playing for longer than a few seconds without giving the user a method of stopping them. An exception is made for loading indicators where there is limited interaction and it might appear to be broken if it were not included.

Accessibility guideline: WCAG 2 - 2.2.2

Do not use more than 3 flashes a second
Type: Accessibility
Flashes in pages may also cause seizures in people with photosensitive epilepsy. Seizures can be triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (such as strobe lights).

For any area of flashing or blinking content, it should not be:

• More than 341 x 256 pixels (approximately 10% of a 1024 x 768 pixel screen), or
• Flashing more than 3 times per second.

Accessibility guideline: WCAG 2 - 2.3.1

Clearly display errors in form entry
Type: Accessibility, Usability
If client-side (JavaScript) validation is used, it should include a pop-up saying which fields had errors, and an error indicator in each label which had an error. Ideally, when the pop-up is dismissed the focus would be put just above the top error message.

WCAG 2 - 3.3.1, 3.3.3
Ensure inserted code is valid
Type: Accessibility
When HTML is added to a page through JavaScript, the resulting HTML should be valid. This can be tested with the "View rendered source" feature in browsers such as Firefox.

Accessibility guideline: WCAG 2 - 4.1.1
Ensure AJAX (partial page updates) is accessible
Type: Accessibility
When part of a page is updated, people using screen readers or screen magnifiers may not be aware that something has changed.

The first issue is that screen readers often use a cached copy of the page, and unless that is updated the user may not have the updated area. This can be solved by adding this script, and calling the function after an update:
http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

The second issue is that, even when available, the person may not know about the updated area of the page.

Making sure that someone using a screen reader knows of an update is tricky. Currently, you can only use content (including a hidden statement to refresh the page after making a change), or allow people to select an option where updates cause JavaScript pop-ups, or an option to turn off scripts.
To make sure people using a screen magnifier can tell something has updated, it is good practice to make it apparent that something is happening where they clicked, as their view follows the mouse very closely.
Use ARIA for custom applications
Type: Accessibility
If custom elements are used, there needs to be a mechanism in the code that identifies what that element is supposed to do. For example, if a custom button is created that shows when it is pressed, then access technology needs know about the name, role, state, properties, and values of that button.

In both HTML and Flash, the default controls already support this, but if non-standard controls are being used, this has to be taken into account.

If there is not an option to 'turn off scripts', then the Accessible Rich Internet Applications (ARIA) specification should be used: http://www.w3.org/WAI/intro/aria.php

ARIA provides methods to make the JavaScript and AJAX widgets work with access technologies.

ARIA works by simply adding attributes to HTML elements. For example, you could define a 'tree' menu with:
<ul role="tree" tabindex="0″ >
<li role="treeitem">First item</li>
[... ]
</ul>

The role defines what type of control it is, the tabindex is used to allow keyboard navigation.
There are various roles defined in the spec that should cover most situations, such as menu, toolbar, slider, tooltip, tree etc.

When using ARIA the tabindex attribute can be used, and is used to add or remove things from the tab order. An un-ordered list cannot normally be focused on when using a keyboard, but adding tabindex="0" will mean that you can, and in the normal order. Using a value of -1 (or less) will allow you to remove things from the tab order, and this can be done dynamically with JavaScript.

You can also say when something has a 'state', such as checked, expanded, and selected. For things that are not links or traditional form controls, this will be vital to match the visual representation.

Using the ARIA attributes, updates to the content can be announced through the 'live' attribute. This can be off, polite, assertive, or rude.  For example, the following section of HTML would have its updates announced:
<div id="myLiveRegion1″ aria-live="assertive">
[updating content]
</div>

The screen reader software can then decide how to deal with the update, announcing a polite update when the user stops what they are doing, or interrupting them with a rude announcement.

NB: Use of ARIA attributes does make the HTML invalid (until HTML5 becomes supported), but it is recommended for the purpose of making a scripted interface accessible.

Accessibility guideline: WCAG 2 - 4.1.2

• Code
• Imprimer

• Commentaire (0)
• �crire

par Avant-premi�re

Annuler r�ponse

�crivez votre commentaire

Commentaires du client sera publi� avant previwed
Donnez votre email r�el pour obtenir des r�ponses notification ou commentaire sera supprim�

Votre nom *
Votre e-mail^g *
Votre site

Comment's Titre

J'assure � 100% je suis humain r�el
Je le r�p�te, je ne suis pas bot

• Sent (0)
• Nouveau