Wikipédia:Atelier accessibilité/Bonnes pratiques

Pour en savoir plus sur l'accessibilité sur Wikipédia, lisez Wikipédia:Atelier accessibilité/Qu'est-ce que c'est ?.

Il ne faut pas confondre l'accessibilité du web, dont on parle ici, avec l'accessibilité numérique.

Les bonnes pratiques ci-dessous sont issues des directives d'accessibilité des contenus Web du Web Content Accessibility Guidelines (WCAG) 2.0).

Elles sont proposées comme un guide pour :

  • la rédaction au quotidien de contenus plus accessibles ;
  • les contributeurs intervenants sur les modèles, les portails ;
  • les administrateurs intervenants notamment sur common.css, common.js, voire certains messages système.

Chaque bonne pratique est marquée d'un degré de priorité en fonction du niveau d'accessibilité WCAG correspondant :

  • priorité élevée : le niveau A d'accessibilité, c'est-à-dire ce qui « doit être fait » ;
  • priorité moyenne : le niveau AA d'accessibilité, c'est-à-dire ce qui « devrait être fait » ; c'est le niveau de référence de tout projet Web par défaut ;
  • priorité faible : le niveau AAA d'accessibilité, c'est-à-dire ce qui « pourrait être fait » dans la mesure du possible, en fonction du type de contenu.

Les problèmes d'accessibilité rencontrés concrètement par les internautes sont de plusieurs sortes :

  • certains sont dus à des erreurs commises par les contributeurs lors de la production du contenu des articles. C'est aux contributeurs de régler le problème et c'est l'objet de cette page ;
  • d'autres sont dus aux bugs des navigateurs et des aides techniques utilisées par les internautes. C'est essentiellement aux développeurs des navigateurs et des aides techniques de régler le problème, mais c'est une question à aborder avec ouverture et prudence : il ne s'agit pas de surcharger les contributeurs de contraintes qui ne relèvent pas de leur responsabilité ; cependant, exceptionnellement, il peut être pertinent de compenser un bug de navigateur ou d'aide technique quand cela ne pose pas de difficulté par ailleurs ;
  • d'autres sont dus aux utilisateurs handicapés eux-mêmes (le problème est souvent entre la chaise et le clavier). C'est à l'utilisateur de recourir à l'outil adapté à ses besoins ;
  • d'autres sont dus à mediawiki et non aux contributeurs qui l'utilisent. C'est aux développeurs de mediawiki de corriger (mais les contributeurs sont les bienvenus pour alerter les développeurs).

Les problèmes évoqués dans cette page sont uniquement ceux qui relèvent de la responsabilité des contributeurs.


Sommaire

Structure des articles

Titres de section

Bonne pratique : utiliser systématiquement les titres de section (==etc.) et ne pas créer de pseudos-titres à l'aide d'une mise en gras ('''), d'une liste de définition (;), d'un élément div mis en forme (<div style="font-weight: bold">), etc.
  • priorité : élevée
  • difficulté : facile

Les titres de section permettent à tous les utilisateurs de percevoir et de comprendre la structure globale de la page. Les utilisateurs de lecteurs d'écran ou de loupe d'écran les utilisent pour explorer celle-ci et y naviguer rapidement. Ils doivent résumer avec concision le contenu de la section[WCAG-TECH 1].

Le modèle ]]

Images décoratives

Icône du Portail de la tour Eiffel Portail de la tour Eiffel

Icône de drapeau: France France

  • priorité : élevée.
  • difficulté : moyenne.

Théoriquement, une image décorative, qui ne porte pas d'information nécessaire à la compréhension de la page, devrait avoir une légende (alternative textuelle) vide, afin d'être ignorée notamment par les synthèses vocales[WCAG-TECH 23].

Mais toute image placée dans une page Wikipédia à l'aide de la syntaxe wiki est en fait une image-lien (vers sa page commons en général). Or, les lecteurs d'écran n'ignorent jamais les images liens, même si leur alternative textuelle est vide. Le plus souvent, ils lisent alors tout ou partie de l'URL de l'image, ce qui n'est pratiquement pas compréhensible pour l'utilisateur.

On ne peut donc pas mettre en pratique sur Wikipédia la règle habituelle d'accessibilité consistant à donner une alternative textuelle vide à une image décorative. On s'efforcera d'indiquer une alternative aussi explicite que possible, qui indique que le lien a pour cible la page de l'image.

Autant que possible, on privilégiera également le passage par une classe CSS ajoutée à common.css pour gérer ces images décoratives sous forme d'arrière-plan CSS (background-image) qui ne posent pas ce type de problèmes d'accessibilité[WCAG-TECH 24]. Pour s'assurer du respect des licences, utiliser une image dans le domaine public ou CC0. Le cas échéant, créditer l'image sur WP:Crédits graphiques.

Bons et mauvais exemples d'images décoratives
Non accessibleAccessible
[[Fichier:P Eiffel.png|48x24px|]][[Fichier:P Eiffel.png|48x24px|La tour Eiffel]]
[[Fichier:P Eiffel.png|48x24px|Icône du Portail de la tour Eiffel]]
<div class="bandeau">[[Fichier:icone1.png|]]Contenu textuel du bandeau</div>
<div class="bandeau icone1">Contenu textuel du bandeau</div>

Dans MediaWiki:Common.css :

.bandeau.icone1 {background: url(...icone1.png) no-repeat left center;padding-left: ...px;}

Combinaisons d'images via CSS

Bonne pratique : ne pas utiliser les styles CSS pour combiner deux ou plusieurs images, ou un texte et une image, de manière à produire une pseudo-image combinée, ou une pseudo image cliquable. Privilégier les images réelles et si nécessaire les images cliquables.
  • priorité : élevée
  • difficulté : moyenne

Pour économiser la création de séries d'images exploitant toutes un fond identique, il peut être tentant de recourir aux styles CSS et de superposer deux images (un fond de carte et un point de localisation, par exemple). L'information résultant de la combinaison de ces deux images ne sera cependant perceptible que pour une partie des utilisateurs, qui ont accès au rendu visuel CSS. Par ailleurs, l'image ne sera pas réutilisable ou copiable. Enfin, le rendu pourra être compromis en cas d'agrandissement de la taille des caractères via les options d'accessibilité du navigateur. Ces techniques de composition d'images sont un défaut d'accessibilité au niveau le plus grave[WCAG-TECH 25].

Exemple de combinaison d'images via CSS, non accessible
Rendu espéréRendu sans CSS
ou avec couleurs désactivées
dans un navigateur graphique
Transcription du rendu
dans un lecteur d'écran
Contenu réel publié
Voir la carte administrative
Voir la carte administrative« Lien graphique Voir
la carte administrative »
« Voir la carte
administrative »
Exemple de combinaison d'images via CSS, non accessible
Rendu espéréRendu sans CSS dans un navigateur graphique

Images animées

Bonne pratique : utiliser des animations au format Ogg Theora et éviter les animations au format GIF. Ne pas utiliser une animation uniquement pour produire un clignotement ou des changements brusques de luminosité (effets de flash).
  • priorité : élevée.
  • difficulté : difficile.

Les animations (mouvement, clignotement, défilement) sont une source de difficulté pour les utilisateurs souffrants de trouble de la concentration, ou pour ceux ayant besoin de davantage de temps que prévu pour percevoir et comprendre les étapes successives de l'animation. Il est nécessaire de permettre d'interrompre une animation qui perturbe l'attention, ou plus généralement de fournir les contrôles nécessaires pour mettre celle-ci en pause puis passer à son étape suivante en la relançant.

A cet effet, les normes d'accessibilité prévoient que les animations lancées automatiquement au chargement de la page :

  • ou bien ne doivent pas excéder une durée de 5 secondes[WCAG-TECH 26] (ce qui revient à en faire un élément purement décoratif).
  • ou doivent être dotées de fonctionnalités de contrôle (arrêt, pause, démarrage)[WCAG-TECH 27].
La même animation convertie au format Ogg Theora.

Les images GIF animées ne peuvent pas être dotées de ces contrôles et sont donc considérées comme non accessibles si l'animation est en boucle ou si elle excède 5 secondes (elles ne peuvent qu'être stoppées via la touche escape sans possibilité de redémarrage et sans contrôle précis de l'étape sur laquelle s'effectue l'interruption). En revanche, une animation au format Ogg Theora ne démarre qu'à l'initiative de l'utilisateur et s'accompagne des contrôles utilisateurs nécessaires.

Pour savoir comment faire la conversion de GIF à Ogg Theora, consulter : Conversion d'une animation gif en vidéo Ogg Theora.

Images cliquables

Bonne pratique : renseigner systématiquement l'alternative textuelle globale des ImageMap. Privilégier l'utilisation des ImageMap et éviter la création d'effets graphiques similaires à l'aide de CSS.
  • priorité : élevée.
  • difficulté : facile.

L'extension ImageMap permet de créer des cartes et autres images cliquables respectant les contraintes d'accessibilité :

  • l'image peut avoir son alternative textuelle globale, qui devrait être rédigée sous la forme « carte de… » ou « organigramme de… » par exemple.
  • l'extension génère automatiquement les alternatives textuelles de chaque zone cliquable, à l'aide du lien vers la page concernée.

Il faut en revanche proscrire les pseudos-images MAP réalisées en positionnant des liens HTML sur un fond de carte, le résultat n'étant pas accessible sans le support de CSS.

Bons et mauvais exemples de cartes cliquables
Non accessibleAccessible
<div style="position: relative;">[[Fichier:foo.png|300px]]<span style="position: absolute; top: ...px; left: ...px">[[Lien 1]]</span><span style="position: absolute; top: ...px; left: ...px">[[Lien 2]]</span></div>
<imagemap>Fichier:foo.png|300px|Carte des principales villes de Syldavierect position-du-lien-1 [[lien-1]]rect position-du-lien-2 [[lien-2]]desc position-de-la-description</imagemap>

Galeries

Bonne pratique : renseigner systématiquement le paramètre alt de chaque image dans les galeries réalisées avec <gallery>, de manière à décrire brièvement le sujet de l'image.
Bons et mauvais exemples d'alternatives pour une galerie d'images
Non accessibleAccessible
<gallery>Fichier:Wikipedia-logo-v2-fr.svg|Légende de l'image.Fichier:Exemple.jpg|Légende de l'image.</gallery>
<gallery>Fichier:Wikipedia-logo-v2-fr.svg|Légende de l'image.|alt=Logo de WikipediaFichier:Exemple.jpg|Légende de l'image.|alt=Photographie d'une fleur de tournesol en gros plan</gallery>

Animations, vidéos, fichiers audios

Bonne pratique : utiliser les animations et documents multimédia (Ogg Vorbis, Ogg Theora ou GIF) comme complément et illustration d'une description textuelle d'un processus, et non comme unique moyen de relater celui-ci.
  • priorité : élevée.
  • difficulté : moyenne.

Les « media temporels », c'est à dire les animations, les contenus vidéo ou audio, nécessitent une transcription de l'information sous forme textuelle pour que celle-ci soit accessible à tous :

  • une animation ou une vidéo ne seront pas perceptibles pour un utilisateur n'ayant pas accès au rendu visuel (utilisateur aveugle par exemple, ou utilisateur dont le système n'a pas le support du format Ogg Theora), sauf si l'information visuelle et sonore est disponible dans la même page sous forme textuelle[WCAG-TECH 28].
  • un fichier sonore ne sera pas perceptible pour un utilisateur n'ayant pas accès au rendu sonore (utilisateur sourd, par exemple, utilisateur dont le système n'a pas le support du format Ogg Vorbis, ou utilisateur n'ayant pas la possibilité d'activer le son dans un contexte donné), sauf si l'information sonore est disponible dans la même page sous forme textuelle[WCAG-TECH 29].

Le moyen le plus direct de disposer de cette transcription est de privilégier, lors de la rédaction, le contenu textuel des articles. Autrement dit, il s'agit de décrire (d'abord) dans le texte les informations qui peuvent (ensuite) être illustrées par un document multimédia ou une animation.

Frises chronologiques

Bonne pratique : à déterminer.

L'extension permettant de créer des frises chronologiques ne tenant pas compte des contraintes d'accessibilité et ne permettant pas de donner une alternative textuelle à ces images, l'utilisation de <timeline> est déconseillée.

À réévaluer, le résultat dépend de la manière dont l'extension est utilisée :

  • le résultat est une image MAP potentiellement accessible si les légendes sont des liens.
  • mais l'extension ne génère aucune alternative textuelle lorsque les légendes sont du texte brut.

Formules mathématiques

Bonne pratique : à déterminer.

Formules chimiques

Bonne pratique : à déterminer.

Styles CSS

Pseudo contenu CSS

Bonne pratique : réserver l'usage des styles CSS exclusivement à la mise en forme de l'information contenue dans l'article, et ne l'utiliser en aucun cas pour créer une information nouvelle.
  • priorité : élevée.
  • difficulté : moyenne.

Le rôle fondamental des styles CSS est de permettre la séparation du contenu structuré et de sa présentation : les styles CSS ne portent aucune information de contenu, et ne servent qu'à mettre en forme ce dernier.

Ceci contribue de manière essentielle à l'accessibilité : cette séparation permet en effet aux navigateurs et aux aides techniques d'adapter aisément la mise en forme du contenu aux besoins de l'utilisateur.

Cependant, il existe plusieurs dérives possibles de l'utilisation des styles CSS, qui vont totalement à l'encontre de ce principe de séparation, en générant via les styles CSS un « pseudo-contenu » dépendant en tout ou partie de la mise en forme. C'est le cas notamment :

  • des légendes de cartes, de tableaux ou de diagrammes où les couleurs ou icônes sont des arrières-plans (background) CSS.
  • des cartes de géolocalisation où une image ou un point sont positionnés via CSS sur un fond de carte vierge
  • des images génériques colorées via CSS

La consultation d'un article avec ou sans activation des styles CSS ne doit entraîner aucune perte d'information[WCAG-TECH 30].

Ces détournements de CSS devraient être remplacés par des contenus HTML indépendants de la mise en forme, c'est-à-dire dans la plupart des cas des images complètes. Le niveau de faisabilité est variable selon le nombre d'images concernées (il est par exemple faible dans le cas de la géolocalisation, en l'absence d'une extension dédiée permettant de générer automatiquement les très nombreuses images de remplacement nécessaires).

« La légende de graphique », exemple de pseudo-contenu CSS et de rendus non accessibles
Rendu espéréRendu sans CSS
dans un navigateur graphique
Résultats à l'élection présidentielle française en 2007
Légende
     - Nicolas Sarkozy
     - Ségolène Royal
     - François Bayrou
     - Jean-Marie Le Pen
     - Olivier Besancenot
     - Philippe de Villiers
     - Marie-George Buffet
     - Dominique Voynet
     - Arlette Laguiller
     - José Bové
     - Frédéric Nihous
     - Gérard Schivardi
Résultats à l'élection présidentielle française en 2007
Légende
- Nicolas Sarkozy
- Ségolène Royal
- François Bayrou
- Jean-Marie Le Pen
- Olivier Besancenot
- Philippe de Villiers
- Marie-George Buffet
- Dominique Voynet
- Arlette Laguiller
- José Bové
- Frédéric Nihous
- Gérard Schivardi
« Le maillot », exemple de pseudo-contenu CSS et de rendus non accessibles
Rendu espéréRendu sans CSS
dans un navigateur graphique
Rendu avec CSS
par défaut
Transcription du rendu dans un lecteur d'écranContenu réel publié
Couleurs de l’équipe
Couleurs de l’équipe
Couleurs de l’équipe
Couleurs de l’équipe
Couleurs de l’équipe
De 1970 à 1973
Couleurs de l’équipe
Couleurs de l’équipe
Couleurs de l’équipe
Couleurs de l’équipe
Couleurs de l’équipe
De 1970 à 1973
Maillot avec mauvais css.png
De 1970 à 1973
« Lien graphique Team colour
Lien graphique Team colour
Lien graphique Team colour
Lien graphique Team colour
Lien graphique Team colour
De 1970 à 1973 »
« Team colour Team colour Team colour
Team colour Team colour De 1970 à 1973 »

Javascript

Javascript est utilisé sur Wikipédia :

Du point de vue de son accessibilité :

  • javascript doit être utilisé de manière compatible avec l'accessibilité : tout contenu ou élément d'interface modifié ou créé via javascript doit respecter l'ensemble des règles d'accessibilité ;
  • en revanche, un script respectant cette première condition n'a pas à être doté d'une alternative : contrairement à WCAG1.0, les normes d'accessibilité WCAG2.0 n'exige en effet pas d'alternative à javascript pour les utilisateurs n'ayant pas le support de cette technologie ou ayant désactivé celui-ci.

Produire un code compatible avec l'accessibilité

Bonne pratique : s'assurer que chaque fonctionnalité ou information ajoutée via javascript respecte elle-même l'ensemble des bonnes pratiques d'accessibilité, notamment la présence de alternatives textuelles, les liens explicites, etc.
  • priorité : élevée.
  • difficulté : moyenne.

Les lecteurs de l'encyclopédie en situation de handicap personnel ou technique n'auront pas nécessairement désactivé le support de javascript dans leur navigateur. Il est donc nécessaire que tout contenu généré via javascript soit accessible en lui-même, c'est-à-dire qu'il comporte en particulier l'ensemble des éléments et attributs nécessaires indiqués dans les bonnes pratiques d'accessibilité[WCAG 1].

Bons et mauvais exemples de javascript
Non accessibleAccessible
var image = document.createElement('img');image.src = 'http://example.org/foo.png';
var image = document.createElement('img');image.src = 'http://example.org/foo.png';image.alt = 'Ici, alternative textuelle pertinente pour cette image';
var lien = document.createElement('a');lien.href = 'http://example.org';lien.appendChild(document.createTextNode('+');
var lien = document.createElement('a');lien.href = 'http://example.org';lien.appendChild(document.createTextNode('+');lien.title = 'Ici, texte explicitant la cible du lien';

Accessibilité au clavier

Bonne pratique : s'assurer que chaque interaction reposant sur javascript pourra être réalisée au clavier aussi bien qu'à la souris.
  • priorité : élevée.
  • difficulté : moyenne.

Tous les lecteurs de Wikipédia n'ont pas la possibilité d'utiliser une souris ou un dispositif de pointage équivalent. S'assurer que chaque interaction est également possible via la touche tabulation du clavier garantit que tous auront accès à cette interaction indépendamment de leur périphérique de saisie[WCAG-TECH 31].

L'un des principaux points clés à respecter est de n'utiliser le gestionnaire d'événement onclick que sur des éléments qui sont sémantiquement destinés à produire un lien ou un contrôle, et de ne jamais l'utiliser sur des éléments tels que span, div ou img[WCAG-TECH 32].

Onclick peut être utilisé de manière accessible sur les éléments :

  • a
  • input de type submit, reset, image, button, radio et checkbox
  • button
  • area
Bons et mauvais exemples de code généré en javascript
Non accessibleAccessible
<span onclick="maFonction();">    Lorem ipsum</span>
<a href="#" onclick="maFonction(); return false;">    Lorem ipsum</a>
<img src="bouton.gif" alt="Lorem ipsum" onclick="maFonction();" />
<a href="#" onclick="maFonction(); return false;">    <img src="bouton.gif" alt="Lorem ipsum" /></a>

Redirections et rafraîchissements de page

Bonne pratique : ne pas utiliser javascript pour produire une redirection automatique ou un rafraîchissement que l'utilisateur ne peut pas désactiver.
  • priorité : faible.
  • difficulté : facile.

Les redirections automatiques via javascript affichent une page temporaire qui déclenche la redirection vers la page finale après un délai donné. De même, un script de rafraîchissement provoque le rechargement automatique de la page toutes les n secondes.

Quelle que soit la temporisation choisie, des utilisateurs d'aide technique auront des difficultés à consulter ces pages dans le délai fixé : l'accès peut être en effet beaucoup plus lent pour un utilisateur naviguant au clavier, recourant à une loupe ou encore à un lecteur d'écran. Ce type de script est donc à éviter autant que possible[WCAG-TECH 33].

Si nécessaire, il est possible cependant de rendre accessible les rafraîchissements et redirections via javascript :

  • en veillant à insérer en tout début de contenu de page, et de manière visible à l'affichage, un lien permettant à l'utilisateur de désactiver celles-ci.
  • ou encore en permettant à l'utilisateur de configurer la durée d'affichage avant la redirection ou le rafraîchissement.

Notes et références

  1. Chaque image a un attribut alt, sur le site AnySurfer, consulté le 18 mars 2014.
  2. voir ce commentaire d'un non voyant : Wikipédia:RAW/2013-09-13#Dans_les_coulisses_de_la_Wikimedia
  1. Précision : L'algorithme à utiliser est celui de luminosité, et pas celui de différence des couleurs.
  2. Cette approche est en cours de normalisation en particulier dans HTML5: Techniques for providing useful text alternatives, W3C Working Draft 25 May 2011.

Les références suivantes mènent à la version originale en anglais des Règles pour l'accessibilité des contenus Web (WCAG) 2.0 :

Les références suivantes mènent à la version originale en anglais des Techniques pour WCAG2.0 :

  1. Using h1-h6 to identify headings, niveau d'accessibilité A.
  2. Presenting repeated components in the same relative order each time they appear, niveau d'accessibilité AA.
  3. Using semantic markup to mark emphasized or special text et Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text, niveau d'accessibilité A
  4. Failure of Success Criterion 1.3.3 due to identifying content only by its shape or location, niveau d'accessibilité A
  5. F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information, niveau d'accessibilité A.
  6. Providing text alternatives for ASCII art, emoticons, and leetspeak et Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text alternative, niveau d'accessibilité A
  7. Using language attributes to identify changes in the human language, niveau d’accessibilité AA.
  8. Unusual Words, niveau d'accessibilité AAA
  9. Providing the expansion or explanation of an abbreviation, niveau d'accessibilité AAA
  10. Identifying the purpose of a link using link text combined with its enclosing list item, Identifying the purpose of a link using link text combined with its enclosing paragraph, Identifying the purpose of a link using link text combined with its enclosing table cell and associated table headings, Identifying the purpose of a link using link text combined with the preceding heading element, Identifying the purpose of a link in a nested list using link text combined with the parent list item under which the list is nested, niveau d'accessibilité A
  11. Identifying the purpose of a link using link text combined with the text of the enclosing sentence, niveau d'accessibilité A ; Providing link text that describes the purpose of a link, niveau d'accessibilité AAA
  12. Ensuring that additional visual cues are available when text color differences are used to convey information, niveau d'accessibilité A
  13. Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text, niveau d'accessibilité AA
  14. Using ol, ul and dl for lists, niveau d'accessibilité A
  15. Using the scope attribute to associate header cells and data cells in data tables, niveau d'accessibilité A.
  16. Using caption elements to associate data table captions with data tables, niveau d'accessibilité A.
  17. Using id and headers attributes to associate data cells with header cells in data tables, niveau d'accessibilité A
  18. Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables, niveau d'accessibilité A
  19. Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized, niveau d'accessibilité A
  20. G115: Using semantic elements to mark up structure, niveau d'accessibilité A
  21. Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content et Providing long description for non-text content that serves the same purpose and presents the same information niveau d'accessibilité A.
  22. G74: Providing a long description in text near the non-text content, with a reference to the location of the long description in the short description, niveau d'accessibilité A.
  23. Using null alt text and no title attribute on img elements for images that AT should ignore, niveau d'accessibilité A
  24. Using CSS to include decorative images, niveau d'accessibilité A
  25. Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS, niveau d'accessibilité A
  26. Setting animated gif images to stop blinking after n cycles (within 5 seconds), niveau d'accessibilité A
  27. Allowing the content to be paused and restarted from where it was paused, niveau d'accessibilité A
  28. Providing an alternative for time based media, niveau d'accessibilité A
  29. Providing an alternative for time-based media for audio-only content, niveau d'accessibilité A
  30. Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS, niveau d'accessibilité A
  31. Providing keyboard-triggered event handlers, niveau d'accessibilité A
  32. 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 et Making actions keyboard accessible by using the onclick event of anchors and buttons
  33. Failure of Success Criterion 2.2.1 due to using server-side techniques to automatically redirect pages after a time-out et Failure of Success Criterion 3.2.5 due to complete change of main content through an automatic update that the user cannot disable from within the content, niveau d'accessibilité AAA