PERCEPTIBLE : Règle 1.3 Adaptable
Règle 1.3 Adaptable : créer un contenu qui puisse être présenté de différentes manières sans perte d'information ni de structure (par exemple avec une mise en page simplifiée).
Comprendre la règle 1.3 (en anglais)
La règle 1.3 couvre beaucoup de terrain et touche à la distinction entre contenu structure et interaction. En (X)HTML, elle fait appel à un codage sémantique des contenus.
Table des matières
- Perception de la structure
- Les formulaires
- Les tableaux de données
- l'ordre de lecture
- Les caractéristiques sensorielles
Perception de la structure
Le problème
Un contenu web ou électronique est généralement subdivisée en sections qui sont coiffées par un titre ou en-tête de section qui est mis en évidence par différents effets de présentation (gras, gros caractères, couleur, etc.).
Ces repères sont importants pour comprendre la structure du document et pour trouver plus rapidement le contenu qui intéresse le lecteur. Si ces indices visuels ne sont pas codés correctement, ils ne seront pas reconnus par les outils d’adaptation comme les lecteurs d’écran.
Lorsque les en-têtes de section sont bien codés, une personne ayant des limitations visuelles pourra les utiliser pour se déplacer rapidement au contenu qui l’intéresse. Elle ne sera donc pas obligée de lire toute la page pour trouver la section qui l’intéresse.
Pour une personne ayant des limitations motrices qui l’oblige à naviguer sans l’aide de la souris, des en-têtes de section bien codés deviennent aussi des cibles qu’un navigateur ou un module complémentaire peut utiliser pour se déplacer directement à un contenu donné.
Pour une personne ayant des limitations cognitives et qui lit une page simultanément de façon visuelle et auditive (en synthèse vocale), les repères visuels sont également donnés de façon vocale.
Les listes et les citations sont des informations de structure importantes. Ces informations sont données à l’utilisateur par un lecteur d’écran pour les personnes aveugles. À l’entrée dans une liste, le lecteur d’écran indique à l’utilisateur le nombre d’items inclus dans la liste et si cette liste comprend des sous-listes imbriquées.
Si une liste est simplement présentée comme une suite de lignes ou, pire, comme un tableau avec une colonne pour les puces et une autre pour les contenus, l’utilisateur aveugle perd cette information précieuse qu’une personne sans limitations fonctionnelles peut constater d’un seul coup d’œil.
De même, il ne faut pas abuser des items de liste et des blocs de citation pour créer un effet visuel de retrait car l’information transmise par le lecteur d’écran sera faussée et induira l’utilisateur en erreur.
La solution
- Les en-têtes de section < h1 > à < h6 > constituent des points de repère extrêmement importants pour les personnes qui ne peuvent compter sur une vision globale de la page pour se faire une idée de son organisation ou naviguer dans le contenu sans souris ;
- Les personnes aveugles, malvoyantes ou ayant des limitations motrices ou cognitives pourront donc parcourir les en-têtes de section qui constitueront pour ainsi dire une table des matières de la page ;
- Les en-têtes doivent constituer une structure logique avec au moins un < h1 >, des < h2 > pour marquer le début des grandes sections et des < h3 > pour le début des sous-sections ;
- Les niveaux d'en-tête de section doivent former une progression continue.
Exemple de code
<h1> LES RÈGLES À SUIVRE.</h1>
...
<h2> Références.</h2>
...
<h2> Deux thèmes majeurs.</h2>
...
<h3> Assurer une transformation
élégante.</h3>
...
<h3> Rendre le contenu compréhensible et
navigable.</h3>
...
<h4> le système de navigation.</h4>
...
<h2> Les règles.</h2>
- Les énumérations présentées sous forme de listes doivent être codées comme des listes ;
- Les balises de liste doivent être utilisées seulement dans un contexte de liste ;
- Coder les menus sous forme de listes afin que l’utilisateur sache dès l’entrée s’il s’agit d’un petit menu ou d’un menu plus long ;
- S’il y a des sous-menus, ils doivent être codés comme des listes imbriquées ;
- Ne pas abuser de listes imbriquées qui sont beaucoup plus
difficiles à comprendre pour les personnes qui n'en ont pas une vision
globale ;
- Se limiter à un maximum de 3 niveaux et utiliser le plus souvent possible des listes à un seul niveau en remplaçant par exemple un niveau de liste par des en-têtes de section.
- Les citations d'un ou de plusieurs paragraphes doivent être codées comme telles à l'aide de la balise <blockquote> ;
- La balise <blockquote> ne doit pas être utilisée pour créer un effet de retrait s'il ne s'agit pas d'une citation car cet effet visuel doit être géré par la feuille de style CSS ;
- Le texte mis en évidence par divers procédés (gras, italique, plus
gros caractères, police particulière, etc.) doit être balisé
sémantiquement pour donner la même information ;
- Si cela n'est pas possible, l'information véhiculée par les changements dans la présentation du texte doit être redonnée en texte (visible ou non).
- Le balisage doit être utilisé de façon sémantique, chaque type de balises jouant le rôle pour lequel il a été conçu ;
- Selon ce même principe, on ne peut inclure du contenu informatif en utilisant les pseudo classes :before et :after la feuille de style CSS ;
- De même, tout balisage de présentation doit être exclu car la présentation doit être gérée entièrement par le feuille de style CSS.
Exemple de code
<blockquote>
<p lang="en">Mark up quotations. Do not use
quotation markup for formatting effects such as
as indentation.</p>
<p><cite>WCAG 1.0, point de contrôle 3.7
</cite></p>
</blockquote>
Les règles qui s’appliquent
WCAG 2.0
1.3.1 Information et relations : l'information, la structure et les relations véhiculées par la présentation peuvent être déterminées par un programme informatique ou sont disponibles sous forme de texte. (Niveau A)
Comment satisfaire à 1.3.1 (en anglais) | Comprendre 1.3.1 (en anglais)
Techniques suffisantes
Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable:
- G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)
- G117: Using text to convey information that is conveyed by variations in presentation of text
- G140: Separating information and structure from presentation to enable different presentations
- Making information and relationships conveyed through presentation programmatically determinable using the following techniques:
Situation B: The technology in use does NOT provide the semantic structure to make the information and relationships conveyed through presentation programmatically determinable:
- G117: Using text to convey information that is conveyed by variations in presentation of text
- Making information and relationships conveyed through presentation programmatically determinable or available in text using the following techniques:
Échecs fréquents à éviter
- F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text
- F42: Failure of Success Criterion 1.3.1 and 2.1.1 due to using scripting events to emulate links in a way that is not programmatically determinable
- F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content
- F62: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine specific relationships in XML
- F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using :before and :after pseudo-elements and the 'content' property in CSS
SGQRI
008-01 : Accessibilité d'un site Web
- 10 b) comporter des balises utilisées exclusivement aux fins pour lesquelles elles ont été créées ;
- 16 d) l’indication de tout en-tête de section, codée de la façon appropriée ;
- 16 e) l’indication de toute liste, codée de la façon appropriée ;
- 16 f) au moins un en-tête de section de premier niveau qui reflète la nature ou la fonction du contenu de la page.
008-02 : Accessibilité d'un document téléchargeable
- 07 c) Un en-tête de section identifiable visuellement doit être identifiable aussi mécaniquement par les technologies d’adaptation informatiques.
008-03 : Accessibilité du multimédia dans un site Web
- S.O
Les formulaires
Le problème
Note : d’autres aspects de l’accessibilité des formulaires sont aussi traités aux règles 2.4 (Navigation) et 3.3 (aide à la saisie).
Pour être utilisable par une personne aveugle, un formulaire doit associer correctement les étiquettes et les champs de formulaire afin qu’un lecteur d’écran puisse indiquer l’étiquette qui correspond au champ à remplir. Une association visuelle ne suffit pas car il faut que cette association soit créée dans le code de la page pour qu’un lecteur d’écran puisse l’interpréter correctement, sans avoir à jouer aux devinettes, avec la marge d’erreur que cela suppose.
Les personnes ayant des limitations motrices auront de la difficulté à sélectionner un bouton radio ou une case à cocher qui occupent une très petite surface à l’écran. Toutefois, lorsque l’étiquette et le champ sont correctement associés, l’utilisateur pourra cliquer n’importe où dans l’étiquette pour cocher ce type de champ.
La solution
- Vous devez associer explicitement les étiquettes et les champs correspondants avec l'attribut for qui reprend le id du champ auquel il est associé ;
- Vous devez donc donner un attribut id unique à chaque champ de formulaire ;
- Donner à chaque balise <label> un attribut for qui reprend exactement le contenu de l'attribut id du champ correspondant.
- À moins que vous disposiez d'un outil spécialisé, cette association doit généralement être faite manuellement dans le code.
Exemple de code
<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>
- Lorsque qu'aucune étiquette n'est visible, vous devez placer la description du champ dans l'attribut title. C'est une des rares situations où les lecteurs d'écran liront le contenu de l'attribut title automatiquement. Il ne faut pas oublier cependant que l'étiquette joue un rôle explicatif pour tous vos visiteurs et qu'il est donc préférable d'avoir une étiquette pour tout champ dont la fonction pourrait être ambiguë.
Exemple de code
<form method="post" action="unepage.html">
<p>
<input id="recherche" title="Recherche :"
name="rech" type="text" />
</p>
</form>
- Lorsque c'est pertinent, les groupes d'options dans un champs de liste doivent être identifiés à l'aide de la balise <optgroup> et de l'attribut « label ».
Exemple de code
<form action="http://example.com/prog/someprog"
method="post">
<label for="food">What is your favorite
food?</label>
<select id="food" name="food">
<optgroup label="Fruits">
<option value="1">Apples</option>
<option value="3">Bananas</option>
<option value="4">Peaches</option>
<option value="5">...</option>
</optgroup>
<optgroup label="Vegetables">
<option value="2">Carrots</option>
<option value="6">Cucumbers</option>
<option value="7">...</option>
</optgroup>
<optgroup label="Baked Goods">
<option value="8">Apple Pie</option>
<option value="9">Chocolate Cake</option>
<option value="10">...</option>
</optgroup>
</select>
</form>
Les règles qui s’appliquent
WCAG 2.0
1.3.1 Information et relations : l'information, la structure et les relations véhiculées par la présentation peuvent être déterminées par un programme informatique ou sont disponibles sous forme de texte. (Niveau A)
Comment satisfaire à 1.3.1 (en anglais) | Comprendre 1.3.1 (en anglais)
Techniques suffisantes
Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable:
- Making information and relationships conveyed through presentation programmatically determinable using the following techniques:
- H44: Using label elements to associate text labels with form controls (HTML)
- H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
- FLASH32: Using auto labeling to associate text labels with form controls (Flash)
- FLASH29: Setting the label property for form components (Flash)
- FLASH25: Labeling a form control by setting its accessible name (Flash)
- H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)
- H85: Using OPTGROUP to group OPTION elements inside a SELECT (HTML)
Situation B: The technology in use does NOT provide the semantic structure to make the information and relationships conveyed through presentation programmatically determinable:
Échecs fréquents à éviter
- F17: Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine one-to-one relationships (e.g., between labels with same id) in HTML
- F68: Failure of Success Criterion 1.3.1 and 4.1.2 due to the association of label and user interface controls not being programmatically determinable
SGQRI
008-01 : Accessibilité d'un site Web
- 21 b) pour tout champ, comporter une étiquette codée de la façon appropriée ou lorsque l’espace est insuffisant pour placer une étiquette, la description de la fonction du champ concerné codée de la façon appropriée ;
- 21 c) pour tout champ associé à une étiquette, comporter un nom unique codé de la façon appropriée ;
008-02 : Accessibilité d'un document téléchargeable
- 14 a) Un champ de formulaire doit avoir une étiquette identifiable mécaniquement par une technologie d’adaptation informatique ou un texte d’aide décrivant la fonction de ce champ quand l’espace est insuffisant pour placer une étiquette.
008-03 : Accessibilité du multimédia dans un site Web
- 15 b) Un champ de formulaire doit avoir une étiquette ou une infobulle d’aide identifiable mécaniquement par une technologie d’adaptation informatique
Les tableaux de données
Le problème
Les tableaux de données constituent un environnement complexe pour les utilisateurs aveugles ou malvoyants parce qu'ils ne peuvent en avoir une vision globale qui leur permettrait d'en comprendre facilement l'organisation.
Pour qu’un lecteur d’écran soit en mesure de percevoir les relations entre les données et les en-têtes qui leur donnent un sens, les cellules d’en-tête doivent être distinguées des cellules de données et les relations entre les cellules doivent être explicitées lorsqu’il s’agit de tableaux complexes.
La solution
- Pour un tableau simple, il s'agit seulement de distinguer les cellules d'en-tête <th> des cellules de données <td> ;
- Les lecteurs d'écran pourront ainsi indiquer à l'utilisateur le titre de la colonne ou de la ligne où il se trouve ;
- Si un titre de tableau est utilisé, il ne doit pas être inclus dans le tableau (ex. dans une cellule fusionnée occupant toute la première rangée) mais présenté avec l'élément <caption> ;
- À moins que la structure du document ne l'indique un titre de tableau devrait être codé avec l'élément <caption> plutôt qu'avec un en-tête de section.
Exemple de code
<table>
<tr>
<th>Date</th>
<th>Sujets</th>
</tr>
<tr>
<td>Jeudi 26 juin 2008</td>
<td>Module 3</td>
</tr>
<tr>
<td>Vendredi, 27 juin 2008</td>
<td>Module 4</td>
</tr>
</table>
Date Sujets Jeudi 26 juin 2008 Module 3 Vendredi, 27 juin 2008 Module 4
- Pour les tableaux de données complexes qui ont plus d'une ligne de titres ou plus d'une colonne de titres, vous devez associer explicitement toutes les cellules, sauf celles de la première ligne et de la première colonne, avec toutes les cellules d'en-têtes correspondantes ;
- Il faut donc d'abord assigner un attribut id unique (pour l'ensemble de la page) à chaque cellule d'en-tête ;
- Par la suite, il faut incorporer un attribut headers à chaque cellule de données ;
- Cet attribut placera entre guillemets et séparés par un espace tous les id des cellules de titre qui s'appliquent à la cellule courante.
- Ce travail doit habituellement être réalisé à la main directement dans le code, car la plupart des logiciels auteurs n'ont pas prévu d'interface pour ce faire.
Exemple de code
<tr>
<th id="l1c1">Destination</th>
<th id="l1c2">Dates du déplacement</th>
<th id="l1c3">Repas</th>
<th id="l1c4">Hôtel</th>
<th id="l1c5">Transport</th>
<th id="l1c6">Total</th>
</tr>
<tr>
<th id="l2c1" headers="l1c1" rowspan="3">Gaspé</th>
<th id="l2c2" headers="l1c2 l2c1">25 août</th>
<td headers="l1c3 l2c1 l2c2">37</td>
<td headers="l1c4 l2c1 l2c2">112</td>
<td headers="l1c5 l2c1 l2c2">45</td>
<td headers="l1c6 l2c1 l2c2"> </td>
</tr>
<tr>
<th id="l3c2" headers="l1c2 l2c1">26 août</th>
<td headers="l1c3 l2c1 l3c2">27</td>
<td headers="l1c4 l2c1 l3c2">112</td>
<td headers="l1c5 l2c1 l3c2">45</td>
<td headers="l1c6 l2c1 l3c2"> </td>
</tr>
Rapport des frais de voyage Destination Dates du déplacement Repas Hôtel Transport Total Gaspé 25 août 37 112 45 26 août 27 112 45
- Les tableaux de données complexes d’un site Web public ont besoin d'un sommaire et peuvent également bénéficier d'une légende ;
- Le sommaire veut compenser le manque de vision globale de l'utilisateur non-voyant en donnant une brève description de l'organisation du tableau ;
- Il est inscrit dans l'attribut summary et peut être aussi long que nécessaire ;
- Un bon sommaire doit décrire les grandes catégories d'information présentées par colonne et par ligne et signaler les irrégularités éventuelles correspondant aux cellules fusionnées ;
- L'effet recherché ici est une vue d'ensemble, c'est pourquoi il n'est pas utile de reprendre dans le sommaire tous les titres de colonne et de ligne, mais plutôt d'en décrire les grandes catégories.
- La légende, quant à elle, est une information complémentaire qui vient chapeauter un tableau à la façon d'un titre ;
- Elle s'inscrit dans l'élément <caption> qui doit être placé immédiatement sous l'élément <table>.
- ATTENTION : vous ne devez pas inscrire un sommaire vide (summary="") pour les tableaux de présentation, parce que c'est un des critères utilisés par les lecteurs d'écran pour distinguer entre les tableaux de présentation et les tableaux de données ;
- De même, tableaux de mise en page doivent être exempts de titre <caption> et de cellules d'en-tête <th>.
- Des données tabulaires ne doivent pas être formatées avec des espaces pour simuler un balisage correct car l'utilisateur ne pourrait naviguer de cellule en cellule dans un tel tableau avec un lecteur d'écran.
Exemple de code
<table border="1" cellpadding="2"
summary="Ce tableau présente les
frais de voyage. Par lignes, vous
trouverez les destinations et les
dates ainsi qu'un grand total.
Par colonnes, sont présentées les
catégories de dépenses ainsi qu'un
total. Notez que la première
colonne comporte des cellules fusionnées.>
<caption>Rapport des frais de
voyage</caption></table>
[...]
- Quand les titres des colonnes ou des lignes sont longs et qu'il serait fastidieux pour l'utilisateur d'entendre répéter cette information à plusieurs reprises, il est préférable d'utiliser des abréviations ;
- Considérez l’exemple qui suit : « Estimation des dépenses pour les soins de santé par les agences du Gouvernement durant la prochaine décennie » qui pourrait être abrégé par : « Estimation des dépenses ».
- De même, si un tableau comporte déjà des abréviations dans les cellules d'en-tête, on peut utiliser cette même technique pour en donner une interprétation plus compréhensible.
- Par exemple, un calendrier dont les jours de la semaine sont identifiés par deux lettres seulement (lu, ma, me, etc.) et qui serait donc peu compréhensible en synthèse vocale.
Exemples de code
<th abbr="Estimation des dépenses de santé">
Estimation des dépenses pour
les soins de santé par les agences du
Gouvernement durant la prochaine
décennie</th>
ou
<th abbr="lundi">lu</th
Les règles qui s’appliquent
WCAG 2.0
1.3.1 Information et relations : l'information, la structure et les relations véhiculées par la présentation peuvent être déterminées par un programme informatique ou sont disponibles sous forme de texte. (Niveau A)
Comment satisfaire à 1.3.1 (en anglais) | Comprendre 1.3.1 (en anglais)
Techniques suffisantes
Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable:
- Making information and relationships conveyed through presentation programmatically determinable using the following techniques:
- H51: Using table markup to present tabular information (HTML)
- H39: Using caption elements to associate data table captions with data tables (HTML)
- FLASH31: Specifying caption text for a DataGrid (Flash)
- H73: Using the summary attribute of the table element to give an overview of data tables (HTML)
- FLASH23: Adding summary information to a DataGrid (Flash)
- H63: Using the scope attribute to associate header cells and data cells in data tables (HTML)
- H43: Using id and headers attributes to associate data cells with header cells in data tables (HTML)
- FLASH21: Using the DataGrid component to associate column headers with cells (Flash)
Échecs fréquents à éviter
- F33: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to create multiple columns in plain text content
- F34: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to format tables in plain text content
- F46: Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables
- F48: Failure of Success Criterion 1.3.1 due to using the pre element to markup tabular information
SGQRI
008-01 : Accessibilité d'un site Web
- 22 a) pour un tableau de données, comporter des cellules d’en-tête de ligne ou de colonne codées de la façon appropriée ;
- 22 b) dans un tableau complexe de données, comporter un identifiant unique codé de la façon appropriée pour toute cellule d’en-tête et les références aux cellules d’en-tête correspondantes codées de la façon appropriée pour toute cellule de données ;
- 22 c) pour un tableau de présentation, éviter l’usage des attributs et des balises réservés à un tableau de données ;
- 22 e) pour un tableau complexe de données, comporter un résumé, codé de la façon appropriée, qui décrit brièvement les grandes catégories d’information présentées par colonnes et par lignes, et qui note, s’il y a lieu, la présence d’irrégularités dans le nombre de lignes ou de colonnes.
008-02 : Accessibilité d'un document téléchargeable
- 6. Un tableau de données qui ne respecte pas les exigences précisées aux alinéas 9 (a) et 9 (b) doit offrir un hyperlien vers une page Web qui présente une version de ce tableau qui satisfait aux exigences du Standard sur l’accessibilité d’un site Web (SGQRI 008-01).
- 9 a) Un tableau de données doit avoir des cellules d’en-têtes de ligne ou de colonne qui sont identifiables mécaniquement par une technologie d’adaptation informatique.
- 9 b) Dans un tableau de données comptant plus d'une ligne ou plus d'une colonne d'en-tête, une cellule de données doit pouvoir être explicitement associée aux cellules d’en-tête qui s’y appliquent de sorte que cette association puisse être identifiée mécaniquement par une technologie d’adaptation informatique.
008-03 : Accessibilité du multimédia dans un site Web
- S.O.
L’ordre de lecture
Le problème
L'ordre de parcours du contenu est un élément important pour faciliter la compréhension de ce contenu. En HTML ou XHTML, l’ordre de lecture correspond à l’ordre du contenu dans le code source de la page, alors qu’en format PDF, il reflète l’ordre des balises.
C’est dans cet ordre que le contenu sera lu en synthèse vocale pour une personne ayant des limitations visuelles ou cognitives.
Cet ordre sera aussi celui dans lequel le contenu pourra être parcouru au clavier avec la touche tabulation par une personne ayant des limitations motrices qui ne lui permettent pas d’utiliser une souris.
Il peut y avoir plus d’un ordre logique pour un parcours visuel de la page, mais un seul ordre peut être déterminé pour l’accessibilité.
La solution
- Pour corriger ce type de problème, il suffit de modifier l’ordre de présentation du contenu dans le code source, p. ex. l’ordre des <div>.
- Si la page n’utilise pas de tableaux de présentation, cet ordre peut être vérifié en désactivant la feuille de style.
- Bien que les règles d'accessibilité recommandent l'utilisation des feuilles de style CSS pour contrôler la mise en page et la présentation, vous devez vous assurer que vos pages demeurent lisibles sans elles.
- Le but recherché est la compatibilité avec les synthèses vocales et certains appareils mobiles (téléphones, assistants personnels, etc.) et la possibilité de désactiver ou de remplacer la feuille de style du concepteur par celle de l'utilisateur pour obtenir un environnement visuel mieux adapté à certains types de limitations.
- Si la page utilise un ou plusieurs tableaux de présentation, vous devrez les linéariser pour vérifier que l’ordre de lecture est correct.
- ATTENTION : il va sans dire qu’un tableau de données ne doit pas être linéarisé et que dans une page linéralisée, il faudra donc faire absatraction du contenu du tableau de données.
- L'espacement entre la caractères d'un mot ne doit pas être contrôlé par l'insertion d'espaces mais par la feuille de style (letter-spacing).
- Si des changement de direction doivent être indiqués pour un texte qui se lirait de droit à gauche, il faut le faire avec l'attribut dir.
Exemple de code fautif
<table>
<caption>Liste d'universités</caption>
<tr>
<td><strong>Université Bishop's</strong></td>
<td><strong>Université Concordia</strong></td>
</tr>
<tr>
<td>Sherbrooke : (819) 822-9600</td>
<td>Montréal : (514) 848-2424</td>
</tr>
<tr>
<td><strong>Université Laval</strong></td>
<td><strong>Université McGill</strong></td>
</tr>
<tr>
<td>Québec : (418) 656-3333</td>
<td>Montréal : (514) 398-4455</td>
</tr>
<tr>
<td><strong>Université de Montréal</strong></td>
<td><strong>École des HÉC de Montréal</strong></td>
</tr>
<tr>
<td>Montréal : (514) 343-6111</td>
<td>Montréal : (514) 340-6000</td>
</tr>
Liste d'universités Université Bishop's Université Concordia Sherbrooke : (819) 822-9600 Montréal : (514) 848-2424 Université Laval Université McGill Québec : (418) 656-3333 Montréal : (514) 398-4455 Université de Montréal École des HÉC de Montréal Montréal : (514) 343-6111 Montréal : (514) 340-6000
Exemple de code fautif
Présentation linéaire :
Liste des universités
Université Bishop's
Université Concordia
Sherbrooke : (819) 822-9600
Montréal : (514) 848-2424
Université Laval
Université McGill
Québec : (418) 656-3333
Montréal : (514) 398-4455
Université de Montréal
École des HÉC de Montréal
Montréal : (514) 343-6111
Montréal : (514) 340-6000
[...]<table border=”1”>
<caption>Liste des universités</caption>
<tbody>
<tr>
<td><strong>Université Bishop's</strong><br>
Sherbrooke : (819) 822-9600</td>
<td><strong>Université Concordia</strong><br>
Montréal : (514) 848-2424</td>
</tr>
<tr>
<td><strong>Université Laval</strong><br>
Québec : (418) 656-3333</td>
<td><strong>Université McGill</strong><br>
Montréal : (514) 398-4455</td>
</tr>
<tr>
<td><strong>Université de Montréal</strong><br>
Montréal : (514) 343-6111</td>
[...]
Les règles qui s’appliquent
WCAG 2.0
1.3.2 Ordre séquentiel logique : lorsque l'ordre de présentation du contenu affecte sa signification, un ordre de lecture correct peut être déterminé par un programme informatique. (Niveau A)
Comment satisfaire à 1.3.2 (en anglais) | Comprendre 1.3.2 (en anglais)
Techniques suffisantes
- G57: Ordering the content in a meaningful sequence for all the content in the Web page
- Marking sequences in the content as meaningful using one of the following techniques AND G57: Ordering the content in a meaningful sequence for those sequences
- H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text direction inline (HTML)
- H56: Using the dir attribute on an inline element to resolve problems with nested directional runs (HTML)
- C6: Positioning content based on structural markup (CSS)
- C8: Using CSS letter-spacing to control spacing within a word (CSS)
- C27: Making the DOM order match the visual order (CSS)
- FLASH15: Using the tabIndex property to specify a logical reading order in Flash (Flash)
- FLASH37: Using the tabIndex property to specify a logical tab order in Flash (Flash)
Échecs fréquents à éviter
- F34: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to format tables in plain text content
- F33: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to create multiple columns in plain text content
- F32: Failure of Success Criterion 1.3.2 due to using white space characters to control spacing within a word
- F49: Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized
- F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS
SGQRI
008-01 : Accessibilité d'un site Web
- 11 2e alinéa) Toutefois, si cette feuille est désactivée, la page Web doit présenter le même contenu organisé selon un ordre séquentiel logique respectant le contraste de luminosité décrit au paragraphe e) du premier alinéa de l’article 16.
- 18 a) comporter un ordre séquentiel logique détectable par les technologies d’adaptation informatiques ;
- 22 d) pour une information incluse dans un tableau de présentation, respecter un ordre séquentiel logique du contenu une fois cette information restructurée de façon linéaire
008-02 : Accessibilité d'un document téléchargeable
- 7 e) Un document téléchargeable lu avec une technologie d’adaptation informatique doit donner accès à tout son contenu informatif en respectant un ordre séquentiel logique.
- 9 c) Une fois restructurée de façon linéaire, l’information incluse dans un tableau de présentation doit respecter l’ordre séquentiel logique du contenu.
- 12 c) Lorsque l’ordre de présentation du contenu affecte sa signification, un ordre séquentiel logique doit pouvoir être déterminé par les outils d’adaptation informatiques.
008-03 : Accessibilité du multimédia dans un site Web
- 14. En matière de compréhension dans une animation vectorielle :
- c) lorsque l’ordre de présentation du contenu affecte sa signification, un ordre séquentiel logique doit pouvoir être déterminé par les outils d’adaptation informatiques.
Les caractéristiques sensorielles
Le problème
Des indices visuels comme l’indentation sont utilisés pour communiquer de l’information qui doit aussi être donnée en texte pour qu’une personne aveugle puisse les percevoir (par exemple l’indentation d’un message dans un forum de discussion).
De même on ne peut se fier seulement sur le positionnement d’un élément pour en comprendre la nature ou la fonction (par exemple un champ de recherche sans étiquette placé en haut à droite de la page).
Parmi les caractéristiques sensorielles qui peuvent être porteuses d’information, on peut aussi considérer la forme, l’orientation ou le son.
Ce type de situation fait appel à la créativité pour trouver les meilleurs moyens de transmettre une information équivalente.
La solution
- Il n’y a pas de solution « toute faite » à ce genre de problème, l'essentiel étant d’abord de réaliser qu’il y a un problème, puis de faire preuve de créativité ;
- Pour un champ de recherche, on peut remplacer un étiquette manquante par un attribut title qui jouera le même rôle ;
- Dans d’autres situations l’information textuelle équivalente peut être transmise de façon invisible en utilisant par exemple un positionnement CSS hors écran ;
- Il faut cependant éviter d’utiliser visibility:hidden ou display:none qui sont deux propriétés CSS reconnues et appliquées par les lecteurs d’écran ;
- La logique étant que si cette information doit être cachée à un utilisateur voyant, elle doit aussi être cachée à un utilisateur aveugle. Le positionnement hors écran ou l’utilisation d’un gif invisible avec un texte de remplacement demeurent donc les seules options possibles.
- Certains symboles sont utilisés pour communiquer une information (par exemple un crochet, une flèche, un caractère représentant une émoticône ou binette, etc.).
- Plusieurs de ces symboles ne sont pas reconnus par les lecteurs d'écran en synthèse vocale ou en braille et il faut donc utiliser des images (icônes) sur lesquelles un attribut alt pourra donner la signification.
Les règles qui s’appliquent aux caractéristiques sensorielles
WCAG 2.0
1.3.3 Caractéristiques sensorielles : les instructions données pour la compréhension et l'utilisation du contenu ne doivent pas reposer uniquement sur les caractéristiques sensorielles des éléments comme la forme, la taille, l'emplacement visuel, l'orientation ou le son. (Niveau A)
Note : pour les exigences liées à la couleur, se référer à la Règle 1.4.
Comment satisfaire à 1.3.3 (en anglais) | Comprendre 1.3.3 (en anglais)
Techniques suffisantes
Échecs fréquents à éviter
SGQRI
008-01 : Accessibilité d'un site Web
- 17 a) offrant un texte ou une image avec un texte de remplacement pour tout contenu faisant appel à une perception sensorielle pour communiquer une information, indiquer une action, solliciter une réponse ou distinguer un élément visuel ;
008-02 : Accessibilité d'un document téléchargeable
- 10 b) Toute information reposant sur une perception sensorielle autre que la couleur est aussi donnée en texte.
008-03 : Accessibilité du multimédia dans un site Web
- 9 b) Toute information reposant sur une perception sensorielle autre que la couleur est aussi donnée en texte

