Formulaires
Liste des points de contrôle
- Labels correctement positionnés
- Association explicite des labels avec leurs éléments de contrôle
- Division des grands blocs d'information
- Correction des erreurs dans les formulaires
- Contrôle à l'utilisateur
- Texte remplaçable
S'assurer que les labels sont correctement positionnés. 10.2 (P2)
WCAG 1.0, traduction française d'AccessibilitéWeb
Jusqu'à ce que les agents utilisateurs supportent les associations explicites entre labels et contrôles de formulaire, s'assurer que les labels sont correctement positionnés pour tous les contrôles de formulaire avec labels implicitement associés.
Section 508 version anglaise
[No equivalent.]
WCAG 2.0 version de travail, traduction française d'AccessibilitéWeb
- 2.4.6 (niveau AA)
Titres et étiquettes :
Les titres et les étiquette décrivent le sujet ou le but.
Projet de standard du gouvernement du Québec
- 01 - 12, f et 02 - 15, c : Une étiquette doit décrire clairement la fonction du champ auquel elle est associée.
RGAA
10.2 Associer visuellement les étiquettes et champs de formulaire
- Test 10.2.1 : Recherche d'éléments de formulaire ayant des étiquettes mal positionnées.
AccessiWeb
Fiche 11.3 : Est-ce que la disposition des champs de formulaire par rapport aux textes qui leur sont associés ne pose aucune ambiguïté ?
Clientèles visées
- Personnes ayant une incapacité visuelle.
- Personnes ayant une incapacité cognitive.
Explication
Les étiquettes de formulaire doivent être placées à proximité immédiate des champs de formulaire correspondants : au-dessus ou à gauche pour les zones de texte ou de liste et à droite ou à gauche des cases à cocher et des boutons radio. Pour un utilisateur d'un logiciel de grossissement, la disposition verticale d'un formulaire avec les étiquettes immédiatement au-dessus des champs correspondants est l'idéal, parce que même en plus fort grossissement, l'utilisateur pourra voir à la fois l'étiquette et le champ dans sa zone de visualisation.
Il s'agit encore ici de la condition « Jusqu'à ce que les agents utilisateurs... ». Les logiciels d'adaptation comme JAWS supportent l'association explicite depuis plusieurs versions déjà. Toutefois, pour les utilisateurs d'un logiciel de grossissement comme ZoomText, cette condition demeure d'actualité.
Le Projet de standard du gouvernement du Québec précise que cette étiquette doit décrire clairement la fonction du champ auquel elle est associée.
Voir aussi Labels or Instructions in WCAG 2.0.
Associer les labels avec leurs éléments de contrôle de manière explicite. 12.4 (P2)
WCAG 1.0, traduction française d'AccessibilitéWeb
Associer les labels avec leurs éléments de contrôle de manière explicite.
Section 508 version anglaise
[No equivalent.]
WCAG 2.0 version de travail, traduction française d'AccessibilitéWeb
- 1.3.1 (niveau A)
Information et relations :
L’information, la structure et les relations véhiculées par la présentation peuvent être déterminées par programmation ou sont disponibles dans le texte.Erreur à éviter :
- F74 : Ne pas identifier un objet multimédia synchronisé comme version de rechange quand il est utilisé à cette fin.
- F8 : Des sous-titres omettant certains dialogues ou des effets sonores importants.
- F74 : Ne pas identifier un objet multimédia synchronisé comme version de rechange quand il est utilisé à cette fin.
- F75 : Utiliser un objet multimédia synchronisé sans sous-titres quand cet objet multimédia présente plus de contenu que celui présenté sur la page.
- F68 : Utiliser des étiquettes de champs sans la balise <label> ou l’attribut for ou du texte remplaçable à la place d’une étiquette ou de l’attribut title.
- 4.1.2 (niveau A)
Nom, rôle et valeur :
Pour tout composant d’une interface utilisateur (incluant mais sans s’y limiter : un élément de formulaire, un lien ou un composant généré par script), le nom et le rôle peuvent être déterminés par programmation; les états, les propriétés, et les valeurs qui peuvent être mis en place par un utilisateur, peuvent être mis en place par programmation; et les notifications de changement pour ces éléments sont disponibles aux agents utilisateurs, incluant les technologies d’adaptation.
- Note :
Ce critère de réussite s’adresse d’abord aux auteurs qui développent ou programment leurs propres composants d’interface utilisateur. Toutefois, les contrôles HTML standards se conforment déjà à ce critère de réussite lorsqu’ils sont utilisés conformément à la spécification.Erreur à éviter :
- F74 : Ne pas identifier un objet multimédia synchronisé comme version de rechange quand il est utilisé à cette fin.
- F8 : Des sous-titres omettant certains dialogues ou des effets sonores importants.
- F74 : Ne pas identifier un objet multimédia synchronisé comme version de rechange quand il est utilisé à cette fin.
- F75 : Utiliser un objet multimédia synchronisé sans sous-titres quand cet objet multimédia présente plus de contenu que celui présenté sur la page.
- F59 : En HTML, utiliser des scripts pour transformer div ou span en contrôles d’interface utilisateur (pourra être solutionné dans l’avenir).
- F15 : Implémenter des éléments d’interface personnalisés qui n'utilisent pas une API d'accessibilité ou le font de façon incomplète.
- F20 : Ne pas mettre à jour le texte de remplacement quand le contenu non textuel change.
- F68 : L'association entre l'étiquette et le composant d'interface utilisateur ne peut être déterminée par programmation.
- F79 : On ne peut déterminer par programmation si le composant d'interface est sous la zone active ou les notifications de changement d'état ne sont pas disponibles.
- F86 : Une identification n'est pas donnée pour chaque partie d'un champ subdividé en plusieurs partie comme un numéro de téléphone.
Projet de standard du gouvernement du Québec
- 01 - 12, c : Un champ doit avoir un nom unique qui est déterminé à l’aide de l’attribut approprié.
- 01 - 12, d : Une étiquette doit être explicitement associée au champ correspondant à l’aide de l’attribut approprié de la balise <label>.
- 01 - 12, e : Une étiquette doit être positionnée à proximité immédiate du champ auquel elle est associée.
- 01 - 12, h : Un champ de formulaire doit être exempt de texte remplaçable.
- 02 - 15, a : Un champ de formulaire doit avoir une étiquette identifiable mécaniquement par une technologie d’adaptation informatique .
RGAA
12.4 Associer les champs de formulaire à leurs intitulés
- Test 12.4.1 : Absence d'élément de formulaire sans identifiant.
- Test 12.4.2 : Absence d'élément de formulaire sans étiquette associée.
- Test 12.4.3 : Pertinence des étiquettes de contrôle de formulaire.
AccessiWeb
Fiche 11.1 : La balise LABEL et les attributs correspondants (ID, FOR) sont-ils présents ?
Clientèles visées
- Personnes ayant une incapacité visuelle.
- Personnes ayant une incapacité motrice.
- Personnes ayant une incapacité cognitive.
Explication
De plus, vous devez associer explicitement les étiquettes et les champs correspondants avec l'attribut for qui reprend le id du champ auquel il est associé. À moins que vous disposiez d'un outil spécialisé, cette association doit généralement être faite manuellement dans le code.
Elle permettra à un logiciel de lecture d'écran comme JAWS d'identifier l'étiquette sans devoir jouer aux devinettes (avec le risque d'erreur que cela comporte).
De plus, les personnes ayant des problèmes moteurs pour manipuler la souris pourront cliquer n'importe où dans l'étiquette pour sélectionner le champ. Cela sera particulièrement apprécié pour les cases à cocher et les boutons radio qui occupent une très petite surface à l'écran.
Exemple :
<form method="post" action="unepage.html">
<p><label for="pnom">Prénom</label>
<input id="pnom" name="pnom" type="text" /></p>
<p><label for="nomf">Nom de famille</label>
<input id="nomf" name="nomf" type="text" /></p>
</form>Voir aussi Info and Relationships in WCAG 2.0 et Name, Role, Value in WCAG 2.0.
Diviser les grands blocs d'information en groupes plus faciles à gérer lorsque c'est naturel et approprié. 12.3 (P2)
WCAG 1.0, traduction française d'AccessibilitéWeb
Diviser les grands blocs d'information en groupes plus faciles à gérer lorsque c'est naturel et approprié.
Section 508 version anglaise
[No equivalent.]
WCAG 2.0 version de travail, traduction française d'AccessibilitéWeb
- 1.3.1 (niveau A)
Information et relations :
L’information, la structure et les relations transmises par la présentation peuvent être déterminés par programmation ou sont disponibles dans le texte.
Projet de standard du gouvernement du Québec
01 - 12, g : Un regroupement de champs dans un formulaire, par section, par groupe de boutons radio ou de cases à cocher doit être décrit à l'aide des balises <fieldset> et <legend>.
RGAA
12.3 Regrouper les informations de même nature
- Test 12.3.1 : Présence d'un regroupement de contrôles de formulaire dans un élément fieldset.
- Test 12.3.2 : Absence d'éléments fieldset sans élément legend.
- Test 12.3.3 : Pertinence de la légende dans les éléments fieldset.
- Test 12.3.4 : Présence des éléments optgroup.
- Test 12.3.5 : Présence d'un attribut label dans les éléments optgroup.
- Test 12.3.6 : Pertinence du contenu de l'attribut label des éléments optgroup.
AccessiWeb
- Fiche 1.7 : Pour chacune des images MAP, les zones de l'image MAP sont-elles définies juste après la déclaration de l'image MAP?
- Fiche 11.2 : Les textes associés aux champs de formulaire donnent-ils leur fonction exacte?
- Fiche 11.3 : Est-ce que la disposition des champs de formulaire par rapport aux textes qui leur sont associés ne pose aucune ambiguïté?
- Fiche 11.4 : La balise FIELDSET est-elle présente pour encadrer des blocs d'information de même nature?
- Fiche 11.5 : La balise LEGEND est-elle présente pour donner un titre au bloc d'information encadré par la balise FIELDSET?
Clientèles visées
- Personnes ayant une incapacité visuelle.
- Personnes ayant une incapacité cognitive.
Explication
Les longs formulaires devraient être subdivisés en section à l'aide des éléments <fieldset> et <legend>. Un lecteur d'écran comme JAWS répétera alors le contenu de l'élément <legend> pour chacun des champs inclus dans le <fieldset>.
De même, les groupes de boutons radio et les groupes de cases à cocher pourraient être identifiés de la même façon.
Il est d'ailleurs possible d'imbriquer des <fieldset>, mais JAWS ne redonnera que la <legend> hiérarchiquement la plus proche.
Exemple :
<fieldset><legend>Indiquez votre sexe :</legend>
<p><input id="masc" name="sexe" type="radio" checked="checked"
value="masculin" />
<label for="masc">Masculin</label></p>
<p><input id="fem" name="sexe" type="radio" value="féminin" />
<label for="fem">Féminin</label></p></fieldset>Voir aussi Info and Relationships in WCAG 2.0 et Labels or Instructions in WCAG 2.0.
Faciliter la correction des erreurs dans les formulaires. (WCAG 2.0 et Projet de standard du gouvernement du Québec)
WCAG 1.0, traduction française d'AccessibilitéWeb
[Aucun équivalent.]
Section 508 version anglaise
[No equivalent.]
WCAG 2.0 version de travail, traduction française d'AccessibilitéWeb
- 3.3.1 (niveau A)
Identification des erreurs :
Si une erreur de saisie est détectée de façon automatique, l’élément erroné est identifié et l’erreur est décrite à l’utilisateur en texte.
- 3.3.2 (niveau A)
Erreur à éviter :
Étiquettes et instructions :
Des étiquettes ou des instructions sont fournies quand le contenu demande une action de l’utilisateur.
- F82 : Formater visuellement un ensemble de champs pour un numéro de téléphone mais sans inclure une étiquette textuelle pour cet ensemble de champs. On ne peut donc pas se fier uniquement sur l’apparence visuelle d’ensemble pour reconnaître un numéro de téléphone : (___) ___-____.
- 3.3.3 (niveau AA)
Suggestions en cas d’erreur :
Si une erreur de saisie est détectée de façon automatique et que les suggestions de correction sont connues, ces suggestions sont fournies à l'utilisateur, à moins qu'elles ne compromettent la sécurité ou la fonction du contenu.
- 3.3.4 (niveau AA)
Prévention des erreurs (légales, financières ou de données) :
Pour une page web qui demande un engagement légal de l’utilisateur ou une transaction financière, qui modifie ou efface des données sous le contrôle de l’utilisateur dans une banque de données, ou qui soumet la réponse à un test, au moins une des conditions suivantes est vraie :
- Réversibilité :
L’envoi peut être annulé.- Vérification :
Les données entrées par l’utilisateur sont vérifiées pour détecter des erreurs de saisie et on offre à l’utilisateur la possibilité de les corriger.- Confirmation :
Un mécanisme est disponible pour vérifier, confirmer, et corriger les information avant l’envoi final des données.- 3.3.5 (niveau AAA)
Aide :
Une aide contextuelle est disponible.- 3.3.6 (niveau AAA)
Prévention des erreurs (de toute nature) :
Pour une page web qui demande à l’utilisateur de soumettre des données, au moins une des conditions suivante est vraie :
- Réversibilité :
L’envoi peut être annulé.- Vérification :
Les données entrées par l’utilisateur sont vérifiées pour détecter des erreurs de saisie et on offre à l’utilisateur la possibilité de les corriger.- Confirmation :
Un mécanisme est disponible pour vérifier, confirmer, et corriger les information avant l’envoi final des données.
Projet de standard du gouvernement du Québec
- 01 - 12, b : Un champ doit avoir une étiquette inscrite à l’aide de la balise <label> ou un attribut title décrivant la fonction de ce champ quand l’espace est insuffisant pour placer une étiquette.
- 01 - 12, i : Si une erreur de saisie est détectée de façon automatique, l’élément erroné est identifié et l’erreur est décrite à l’utilisateur en texte avec les suggestions de correction lorsqu’elles sont connues.
- 01 - 12, j et 03 - 16, f : Tout procédé ou dispositif d'un site Web qui permet à l'internaute d'engager une responsabilité vis-à-vis de la loi, d'effectuer un paiement ou de transmettre des renseignements nominatifs vers ce site doit offrir les possibilités suivantes :
- l'internaute peut annuler cette opération ;
- l'internaute peut réviser et corriger au besoin l'information avant de confirmer cette opération ;
- l'internaute doit confirmer cette opération.
RGAA
[Aucun équivalent.]
AccessiWeb
[Aucun équivalent.]
Clientèles visées
- Personnes ayant une incapacité visuelle.
- Personnes ayant une incapacité motrice.
- Personnes ayant une incapacité cognitive.
Explication
La version de travail de WCAG 2.0 et le Projet de standard du gouvernement du Québec introduisent de nouvelles exigences pour faciliter l'utilisation des formulaires concernant l'identification des erreurs et la validation de certains types de transactions.
L'exemple qui suit est traduit et adapté des techniques d'application de WCAG 2.0 du W3C.
L'objectif de cette technique est de démontrer comment utiliser les fonctions du modèle objet de document (DOM, pour Document Object Model, en anglais) pour ajouter du contenu à une page au lieu d'utiliser « document.write » ou « object.innerHTML ». L'instruction « document.write() » ne fonctionne pas avec XHTML lorsque servi avec le MIME approprié de type « (application/xhtml+xml) ». Quant à la propriété « innerHTML », elle ne fait pas partie de la spécification du DOM et doit donc être évitée.
Si les fonctions du DOM sont utilisées pour ajouter du contenu, les agents utilisateurs peuvent utiliser le DOM pour retrouver le contenu. La fonction « createElement() » peut être utilisée pour créer des élément dans le DOM. La fonction « createTextNode() » est utilisée pour créer du texte associé à un élément. Les fonctions « appendChild() », « removeChild() », « insertBefore() » et « replaceChild() » sont utilisées pour ajouter ou enlever des éléments ou des nœuds. Les autres fonctions du DOM sont utilisées pour assigner des attributs aux éléments créés.
Notez bien que quand on ajoute des éléments sur lesquels on pourra déplacer la zone active (focus), il est recommandé de ne pas utiliser l'attribut "tabindex" pour définir l'ordre de tabulation puisque l'ajout d'autres éléments dans l'ordre de tabulation au milieu d'un document peut évidemment causer des problèmes. Dans ce cas, il est donc préférable de ne pas modifier l'ordre par défaut en utilisant l'attribut "tabindex".
L'exemple qui suit démontre l'utilisation d'un script « côté client » pour la validation d'un formulaire. Si des erreurs sont détectées, les messages d'erreur appropriés sont affichés. L'exemple utilise les fonctions du DOM pour ajouter un avis d'erreur consistant en un en-tête, un court paragraphe expliquant la détection d'erreurs et une liste numérotée des erreurs identifiées. Le contenu de l'en-tête est codé comme un lien de sorte que l'attention de l'utilisateur peut être sollicitée quand la zone active y est déplacée. Chaque item de la liste est aussi codé comme un lien permettant de déplacer la zone active dans le champ de formulaire en erreur quand ce lien est activé.
Pour simplifier, l'exemple ne valide que deux champs d'édition, mais cette façon de faire pourrait être étendue pour devenir la technique générale de validation d'un formulaire. Toutefois, la validation « côté client » ne devrait pas être la seule validation et devrait être appuyée par une validation « côté serveur ». L'avantage de la validation « côté client » c'est de permettre une rétroaction immédiate pour l'utilisateur qui n'a pas à attendre que l'avis d'erreur lui revienne du serveur. De plus, la validation « côté client » aide à réduire les interactions inutiles avec le serveur.
Voici le script pour ajouter les déclencheurs d'événements au formulaire. Si l'utilisation des scripts est activée, les fonctions sont appelées pour la validation du formulaire avant son envoi. Si l'utilisation des scripts est désactivée, le formulaire est immédiatement envoyé au serveur qui devrait aussi appliquer sa propre validation.
Exemple :
Cet exemple contient deux zones de liste déroulante. Quand un item est sélectionné dans la première liste, la liste de choix de la seconde liste est mise à jour automatiquement via le modèle objet de document (DOM, en anglais). Toute l'information requise est déjà incluse dans la page.
L'exemple qui suit est traduit et adapté des techniques d'application de WCAG 2.0 du W3C.
<script type="text/javascript">
window.onload = initialise;
function initialise()
{
// Ensure we're working with a relatively standards compliant user agent
if (!document.getElementById || !document.createElement || !document.createTextNode)
return;
// Add an event handler for the number form
var objForm = document.getElementById('numberform');
objForm.onsubmit= function(){return validateNumbers(this);};
}
// Function to create a list item containing a link describing the error
// that points to the appropriate form field
function addError(strError, strFragment, objForm, strID)
{
var objAnchor = document.createElement('a');
var objListItem = document.createElement('li');
objAnchor.appendChild(document.createTextNode(strError));
objAnchor.setAttribute('href', strFragment);
objAnchor.onclick = function(event){return focusFormField(this, event, objForm);};
objAnchor.onkeypress = function(event){return focusFormField(this, event, objForm);};
// If strID has a value, this is the first error in the list
if (strID.length > 0)
{
objAnchor.setAttribute('id', strID);
objListItem.appendChild(objAnchor);
return objListItem;
}
}
// Function to place focus to the form field in error
function focusFormField(objAnchor, objEvent, objForm)
{
// Allow keyboard navigation over links
if (objEvent && objEvent.type == 'keypress')
if (objEvent.keyCode != 13 && objEvent.keyCode != 32)
return true;
// set focus to the form control
var strFormField = objAnchor.href.match(/[^#]\w*$/);
objForm[strFormField].focus();
return false;
}
function validateNumbers(objForm)
{
// Test whether fields are valid
var bFirst = isNumber(document.getElementById('num1').value);
var bSecond = isNumber(document.getElementById('num2').value);
// If not valid, display errors
if (!bFirst || !bSecond)
{
var objExisting = document.getElementById('validationerrors');
var objNew = document.createElement('div');
var objTitle = document.createElement('h2');
var objParagraph = document.createElement('p');
var objList = document.createElement('ol');
var objAnchor = document.createElement('a');
var strID = 'firsterror';
var strError;
// The heading element will contain a link so that screen readers
// can use it to place focus - the destination for the link is
// the first error contained in a list
objAnchor.appendChild(document.createTextNode('Erreurs dans la submission du formulaire'));
objAnchor.setAttribute('href', '#firsterror');
objTitle.appendChild(objAnchor);
objParagraph.appendChild(document.createTextNode('Veuillez prendre note des erreurs suivante et les corrigez'));
objNew.setAttribute('id', 'validationerrors');
objNew.appendChild(objTitle);
objNew.appendChild(objParagraph);
// Add each error found to the list of errors
if (!bFirst)
{
strError = 'Veuillez mettre une valeur numérique dans le premier champs';
objList.appendChild(addError(strError, '#num1', objForm, strID));
}
if (!bSecond)
{
strError = 'Veuillez mettre une valeur numérique dans le deuxième champs';
objList.appendChild(addError(strError, '#num2', objForm, strID));
}
if (!bFirst || !bSecond)
strID = '';
// Add the list to the error information
objNew.appendChild(objList);
// If there were existing errors, replace them with the new lot,
// otherwise add the new errors to the start of the form
if (objExisting)
objExisting.parentNode.replaceChild(objNew, objExisting);
else
{
var objPosition = objForm.firstChild;
objForm.insertBefore(objNew, objPosition);
}
// Place focus on the anchor in the heading to alert
// screen readers that the submission is in error
objAnchor.focus();
// Do not submit the form
objForm.submitAllowed = false;
return false;
}
}
// Function to validate a number
function isNumber(strValue)
{
return (!isNaN(strValue) && strValue.replace(/^\s+|\s+$/, '') !== '');
}
</script>
</head>
<body>
<h1>Formulaire Validation</h1>
<form id="numberform" method="post" action="form.php">
<fieldset>
<legend>Champs numérique</legend>
<p>
<label for="num1">Entrer le premier nombre</label>
<input type="text" size="20" name="num1" id="num1" />
</p>
<p>
<label for="num2">Entrer le deuxième nombre</label>
<input type="text" size="20" name="num2" id="num2" />
</p>
</fieldset>
<p>
<input type="submit" name="submit" value="Envoyez le Formulaire" />
</p>
</form>
Vous pouvez tester un exemple fonctionnel de la gestion des erreurs.
Laisser le contrôle à l'utilisateur dans un formulaire. (WCAG 2.0 et Projet de standard du gouvernement du Québec)
WCAG 1.0, traduction française d'AccessibilitéWeb
[Aucun équivalent.]
Section 508 version anglaise
[No equivalent.]
WCAG 2.0 version de travail, traduction française d'AccessibilitéWeb
- 3.2.1 (niveau A)
Zone active (focus) :
Lorsqu’un composant reçoit l’attention, il ne doit pas initier un changement de contexte.- 3.2.2 (niveau A)
À la saisie :
Changer un paramètre d’un composant d’interface ne doit pas entraîner un changement automatique de contexte à moins que l’utilisateur n’ait été avisé de ce comportement avant d’utiliser ce composant.- 3.2.5 (niveau AAA)
Changement sur demande :
Un changement de contexte est initié seulement sur demande de l’utilisateur ou un mécanisme est disponible pour désactivé un tel comportement.Erreur à éviter :
- F60 : Ouvrir automatiquement une nouvelle fenêtre quand l’utilisateur saisit du texte dans un champ.
- F61 : Changer complètement le contenu principal de la page par une mise à jour automatique qu’un utilisateur ne peut désactiver à partir de ce contenu.
- F9 : Changer le contexte quand l’utilisateur déplace la zone active hors d’un champ de formulaire.
- F22 : Ouvrir une nouvelle fenêtre qui n’a pas été demandée par l’utilisateur.
- F41 : Utiliser meta refresh avec une limite temporelle.
Projet de standard du gouvernement du Québec
01 - 12, a et 03 - 16, a: À moins que l’utilisateur ne soit informé avant d’utiliser un champ de formulaire, un changement de contexte doit éviter d’être initié uniquement par la saisie d’information dans ce champ.
RGAA
[Aucun équivalent.]
AccessiWeb
[Aucun équivalent.]
Clientèles visées
- Personnes ayant une incapacité visuelle.
- Personnes ayant une incapacité motrice.
- Personnes ayant une incapacité cognitive.
Explication
Ce type d'exigence s'apparente à ce qui est prévu à propos de l'ouverture automatique de nouvelles fenêtres ou la réactualisation automatique de la page. Il vise à laisser le contrôle de ce type de changements entre les mains de l'utilisateur.
Les zones de liste déroulantes de certains formulaires sont programmées pour modifier automatiquement le formulaire selon le choix qui est inscrit par l'utilisateur. Ce type de mise à jour automatique est interdit, à moins que l'utilisateur n'en soit averti au préalable ou que le changement intervienne dans le contenu qui suit sans rechargement de la page.
Il est possible d'utiliser un déclencheur d'événement onchange dans une zone de liste déroulante pour mettre à jour d'autres éléments de contrôle dans la suite du formulaire.
Exemple de code :
<script type="text/javascript">
var countryLists = new Array();
countryLists["vide"] = ["Choisir un pays"];
countryLists["Amérique du Nord"] = ["Canada", "États-Unis", "Mexique"];
countryLists["Amérique du Sud"] = ["Brésil", "Argentine", "Chili", "Équateur"];
countryLists["Asie"] = ["Russie", "Chine", "Japon"];
countryLists["Europe"]= ["Grande-Bretagne", "France", "Espagne", "Allemagne"];
/* CountryChange() est appelé par le onchange d'une zone de liste déroulante.
* param selectObj - la zone de liste déroulante qui initie le changement.
*/
function countryChange(selectObj)
{
// obtenir l'index de l'option sélectionnée
var idx = selectObj.selectedIndex;
// obtenir la valeur de l'option sélectionnée
var which = selectObj.options[idx].value;
// utiliser la valeur de l'option sélectionnée pour récupérer la liste des items
// du tableau des pays
cList = countryLists[which];
// obtenir l'élément du choix de menu via son identifiant connu
var cSelect = document.getElementById("id_country");
// enlever les items actuels de la sélection de pays
var len=cSelect.options.length;
while (cSelect.options.length > 0)
{
cSelect.remove(0);
}
var newOption;
var letexte = "";
var lavalue = 0;
// créer les nouveaux items
for (var i=0; i < cList.length ; i++)
{
newOption = document.createElement("option");
letexte = document.createTextNode(cList[i]);
newOption.appendChild(letexte);
newOption.setAttribute("value",cList[i]);
cSelect.appendChild(newOption);
}
}
</script>
</head>
<body>
<h1>Zones de listes déroulantes dynamiques</h1>
<form action="#">
<p>
<label for="id_continent">Choisir un continent</label>
<select name="sl_continent" id="id_continent" onchange="countryChange(this);">
<option value="vide">Choisir un continent</option>
<option value="Amérique du Nord">Amérique du Nord</option>
<option value="Amérique du Sud">Amérique du Sud</option>
<option value="Asie">Asie</option>
<option value="Europe">Europe</option>
</select>
</p>
<p>
<label for="id_country">Choisir un pays</label>
<select name="sl_country" id="id_country">
<option value="0">Choisir un pays</option>
</select>
</p>
</form>Vous pouvez tester un exemple fonctionnel de la mise à jour dynamique.
Voir aussi On Focus in WCAG 2.0, On Input in WCAG 2.0 et Change on Request in WCAG 2.0.
Placer du texte remplaçable dans les champs vides de type zones d'édition simples et multilignes. 10.4 (P3)
WCAG 1.0, traduction française d'AccessibilitéWeb
Jusqu'à ce que les agents utilisateurs prennent en compte les champs vides correctement, placer du texte remplaçable dans les champs vides des formulaires de type zones d'édition simples et multilignes.
Section 508 version anglaise
[No equivalent.]
WCAG 2.0 version de travail, traduction française d'AccessibilitéWeb
Exigence retirée
Projet de standard du gouvernement du Québec
01 - 12, g et 02 - 15, d : Un champ de formulaire doit être exempt de texte remplaçable.
RGAA
10.4 Utiliser le texte par défaut des champs de formulaire pour en indiquer la fonction.
AccessiWeb
[Aucun équivalent.]
Explication
Ce point de contrôle est soumis à la condition « jusqu'à ce que les agents utilisateurs... ». Il y a longtemps que cette difficulté a été surmontée par les agents utilisateurs et ce point de contrôle nous apparaît donc désuet.
C'est aussi l'avis des rédacteurs de WCAG 2.0 qui écrivent : « This "until user agents" condition is now met and this checkpoint is no longer required. »
Il est toutefois facile à évaluer par certains outils automatiques et certains préfèreront l'appliquer plutôt que de risquer d'être pris en défaut par le premier évaluateur débutant.
Si vous décidez de l'appliquer, ce texte remplaçable doit être très court. De plus, il serait préférable d'utiliser javascript pour le surligner automatiquement. Sinon, le curseur se placera à la fin du texte remplaçable et l'utilisateur non-voyant pourrait entrer du texte à la suite sans s'en rendre compte.
Voir aussi Technique 10.4 in WCAG 1.0.
