AnySurfer, WCAG et la directive Européenne

Sophie Schuermans le 06/08/2018

La directive Européenne relative à l'accessibilité des sites web et des applications mobiles sera bientôt transposée dans la loi belge (le 23/09/2018 en principe). Les sites web et applications mobiles du service public devront être accessibles. Qu'est ce que cela signifie? Certains sites ont déjà le label AnySurfer. Est-ce que cela suffit pour satisfaire aux exigences de la directive? Que faut-il faire en plus?

Que demande la directive?

La directive demande qu'un site web ou application mobile soit perceptible, utilisable, compréhensible et robuste (voir l'article 4).

Une manière d'atteindre cet objectif est de se conformer à une norme Européenne harmonisée. Le problème c'est que cette norme n'existe pas encore officiellement. Un 'final draft' existe: EN 301 549 V2.1.2.

  • En attendant que la norme harmonisée soit publiée au journal officiel de l'union européenne, on peut utiliser la norme Européenne EN 301 549 V1.1.2 (2015-04) pour se conformer à la directive. Cette norme fait référence à WCAG 2.0 niveau AA.
  • Quand la norme harmonisée aura été publiée, il faudra utiliser cette norme pour se conformer à la directive. Cette norme fait référence à WCAG 2.1 niveau AA

Qu'est-ce que WCAG?

WCAG (Web Content Accessibility Guidelines ou en français 'Règles d'accessibilité pour les contenus web') est une recommandation officielle du W3C pour rendre les contenus web accessibles à un maximum d'utilisateurs. WCAG se compose de critères de succès testables divisés en trois niveaux : A, AA et AAA.

  • WCAG 2.0 est depuis 2008 la norme internationale pour l'accessibilité des sites web.
  • WCAG 2.1 est la nouvelle recommandation du W3C depuis juin 2018. C'est une extension de WCAG 2.0 : tous les critères de succès de WCAG 2.0 font aussi partie de WCAG 2.1, mais de nouveaux critères ont été ajoutés pour prendre mieux en compte les besoins de tous les utilisateurs.

A quoi correspond(ait) le label AnySurfer?

Un site qui porte déjà le label AnySurfer aujourd'hui est au moins conforme à WCAG 2.0 niveau A. Il respecte les 25 critères de succès de WCAG 2.0 niveau A.

Que faut-il faire en plus?

Pour être conforme avec la directive européenne, il faut aller un peu plus loin et respecter aussi les critères de succès de

En étant conforme à WCAG 2.0 niveau A, une bonne partie du travail a déjà été fait. Il se peut que le site soit déjà conforme à certains points WCAG 2.0 AA ou WCAG 2.1 niveau A et AA, mais cela n'a pas été vérifié.

Ce qu'il reste à faire dépend fortement du contenu du site parce que tous les nouveaux critères ne sont pas d'office d'application sur tous les sites.

Pour WCAG 2.0 AA

  • 1.2.4 Sous-titres (en direct) : il faut sous-titres les vidéos en direct.
  • 1.2.5 Audio-description (pré-enregistrée): fournir une audiodescription pour les vidéos qui en ont besoin.
  • 1.4.3 Contraste (minimum): le texte contraste suffisamment avec l'arrière-plan.
  • 1.4.4. Redimensionnement du texte (200%) : l'utilisateur doit pouvoir agrandir le texte ou utiliser le zoom du navigateur sans qu'une partie du texte ne devienne illisible ou invisible.
  • 1.4.5 Texte sous forme d'image : il faut éviter de proposer des textes sous forme d'image sauf quand il n'y a pas moyen de faire autrement
  • 2.4.5 Accès multiples : il faut pouvoir retrouver une page de plusieurs manières dans un site.
  • 2.4.6 En-têtes et étiquettes: les étiquettes des champs et les titre doivent être pertinents.
  • 2.4.7 Focus visible : le focus est visible lors de la tabulation.
  • 3.1.2 Langue d'un passage: il faut indiquer la langue d'un passage dans le code quand elle diffère de la langue de la page.
  • 3.2.3 Navigation cohérente : dans un ensemble de pages, les mécanismes de navigation qui se répètent sur plusieurs pages Web se présentent dans le même ordre relatif chaque fois qu'ils sont répétés.
  • 3.2.4 Identification cohérente : dans un ensemble de pages Web les composants qui ont la même fonctionnalité sont identifiés de la même façon.
  • 3.3.3 Suggestion après une erreur : quand des erreurs sont détectées dans un formulaire et quand c'est possible, il faut faire des suggestions de corrections.
  • 3.3.4 Prévention des erreurs (juridiques, financières, de données): donner une chance à l'utilisateur de se relire ou d 'annuler ce qu'il a fait quand il doit saisir des données destinées à être stockées ou faire une transaction financière ou avec des implications juridiques.

Le point 1.2.4 Sous-titres (en direct) fait partie des exceptions de la directive européenne, donc même s'il fait partie de WCAG 2.0 niveau AA on n'est pas obligé de s'y conformer du point de vue de la directive.

Pour WCAG 2.1

Il n'y a pas encore de traduction officielle de WCAG 2.1. Nous avons décrit brièvement chaque nouveau critère de succès dans WCAG 2.1 - résumé

Prochaines étapes

Pour vous aider à assimiler ces critères de succès:

  • Dans nos rapports, nous structurons désormais nos remarques selon les critères WCAG 2.0 niveau AA, et ajouterons bientôt les critères 2.1.
  • Si vous avez déjà obtenu le label AnySurfer et que vous demandez une prolongation, le minimum à atteindre sera WCAG 2.0 niveau A, mais nous vous fournirons un rapport indiquant la conformité avec les critères double A et WCAG 2.1 afin que vous sachiez où votre site web se situe.
  • Nos formations seront bientôt mises à jour avec WCAG 2.1. Un module séparé WCAG 2.1 sera également disponible.

Conclusion

Le label AnySurfer continue à exister. Il est toujours équivalent à au moins WCAG 2.0 niveau A. La page de statut qui est liée au label spécifie le niveau de conformité atteint.

Nous pouvons vous accompagner pour atteindre le niveau de conformité de votre choix.

Réagissez

WCAG 2.1 : résumé

Sophie Schuermans le 03/08/2018

Le 5 juin 2018 les WCAG (Web Content Accessibility Guidelines), ou Règles pour l'accessibilité des contenus web, ont été mises à jour. La version 2.1 ajoute 17 nouveaux critères. Ci-dessous nous résumons les nouveaux critères de niveau A et AA.

1.3.4 Orientation (AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

Citation d'un utilisateur:

Je veux pouvoir utiliser l'application en mode paysage mais l'écran de mon smartphone ne réagit pas quand je le tourne.

N'obligez pas l'utilisateur à tenir sa tablette ou son smartphone dans un sens particulier (portrait ou paysage). La personne qui l'utilise ne peut peut-être pas le faire pivoter, par exemple parce que l'appareil est fixé à sa chaise roulante.

1.3.5 Identify Input Purpose (AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

  • The input field serves a purpose identified in the Input Purposes for User Interface Components section; and
  • The content is implemented using technologies with support for identifying the expected meaning for form input data

Citation d'un utilisateur:

Je remplis automatiquement mes données dans ce formulaire grâce au navigateur. C'est rapide et je ne fais pas d'erreurs.

Donnez un attribut autocomplete à chaque champ, s'il existe une valeur pour ce champ dans la spécification HTML5 (sous Autofill). C'est provisoirement la manière la plus simple de respecter ce critère.

1.4.10 Reflow (AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels;
  • Except for parts of the content which require two-dimensional layout for usage or meaning.

Citation d'un utilisateur:

Je ne peux pas lire ce texte. Le texte est beaucoup trop petit. Je veux l'agrandir sans devoir scroller horizontalement.

Cela revient à faire du responsive design. Tout doit continuer à fonctionner et être lisible sans défilement horizontal sur une largeur de 320 pixels CSS. Cela peut être testé facilement en redimensionnant la fenêtre du navigateur à 1280 pixels et en zoomant à 400% (cmd ou ctrl +).

1.4.11 Non-text Contrast (AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Citation d'un utilisateur:

Les boutons et les icônes sont difficiles à identifier. J'ai besoin d'un meilleur contraste.

Tous les composants de l'interface utilisateur et les éléments graphiques importants doivent présenter un contraste d'au moins 3 par rapport à la couleur d'arrière-plan. Par exemple, les champs de saisie, boutons, icônes, infographies. C'est facile à tester avec un outil de contraste de couleurs.

1.4.12 Text Spacing (AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Citation d'un utilisateur:

Le texte est trop rapproché, j'ai besoin de plus d'espace pour lire facilement.

L'utilisateur doit pouvoir ajuster l'espace entre les lettres, les mots, les lignes et les paragraphes. Par exemple via une feuille de style personnalisée ou une extension de navigateur. Aucun texte ne peut être coupé ou se chevaucher. Cela peut être facilement testé avec ce bookmarklet de Steve Faulkner.

1.4.13 Content on Hover or Focus (AA)

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

  • Dismissable: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
  • Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
  • Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Citation d'un utilisateur:

Je ne peux pas lire la popup. Elle apparaît en dehors de mon écran parce que j'utilise un logiciel d'agrandissement et disparaît quand j'essaie de l'atteindre.

Le but de ce critère est de donner plus de contrôle à l'utilisateur pour du contenu qui apparaît au survol (hover) ou à la tabulation (focus). Le contenu, par exemple une infobulle doit respecter ces 3 points :

  • Pouvoir être masqué (dismissable): une infobulle apparaît au-dessus du contenu existant et le rend illisible. L'utilisateur peut appuyer sur ESC pour masquer à nouveau l'infobulle.
  • Pouvoir être survolé (hoverable): l'infobulle apparaît lorsque la souris survole une icône avec un point d'interrogation. L'infobulle ne doit pas disparaître lorsque l'utilisateur déplace la souris de l'icône vers le contenu de celle-ci.
  • Être persistant (persistent): l'infobulle ne peut pas disparaître automatiquement, mais seulement lorsque l'utilisateur appuie sur ESC ou en éloigne le pointeur.

2.1.4 Character Key Shortcuts (A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

  • Turn off: A mechanism is available to turn the shortcut off;
  • Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
  • Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Citation d'un utilisateur:

Lorsque j'utilise une commande vocale dans mon application de messagerie (webmail), elle saute de manière inattendue vers un autre courriel.

Les raccourcis clavier qui n'utilisent qu'un seul caractère ne sont utiles que sur les sites web ou les applications utilisées intensivement. Par exemple, avec 'J', vous passez au message suivant dans Gmail. Quand ce type de raccourci existe, l'utilisateur doit pouvoir les désactiver, les lier à une autre touche, ou bien il faut que le raccourci ne soit actif que quand le focus se trouve sur un composant d'interface particulier.

2.5.1 Pointer Gestures (A)

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

Citation d'un utilisateur:

Je souffre de tremblements et ne peux pas glisser mes doigts sur mon portable, donnez-moi un bouton qui remplisse la même fonction.

Tout le monde ne peut pas faire des mouvements nécessitant un chemin particulier (glisser, secouer) ou utiliser plusieurs doigts (pincement). Fournissez un autre moyen d'effectuer ces actions, par exemple des boutons pour effectuer un zoom avant ou arrière sur une carte au lieu de pincer.

2.5.2 Pointer Cancellation (A)

For functionality that can be operated using a single pointer, at least one of the following is true:

  • No Down-Event: The down-event of the pointer is not used to execute any part of the function;
  • Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
  • Up Reversal: The up-event reverses any outcome of the preceding down-event;
  • Essential: Completing the function on the down-event is essential.

Citation d'un utilisateur:

J'ai des difficultés à faire des mouvements précis et j'appuie souvent sur le mauvais bouton sur l'écran de mon smartphone.

Il faut donc donner à l'utilisateur l'occasion d'annuler les actions du pointeur.

Quand un utilisateur appuie pour faire un click (down-event) ou touche l'écran, l'action ne peut être déclenchée qu'au moment ou l'utilisateur relâche la pression (up-event), pas au moment ou il appuie. L'utilisateur doit pouvoir annuler l'action avant ou après le lâcher. Si l'action est déclenchée en appuyant, il faut qu'elle soit annulée au lâcher.

2.5.3 Label in Name (A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Citation d'un utilisateur:

Je ne peux pas envoyer ce formulaire par commande vocale. Il a un bouton 'envoyer' mais 'cliquer sur envoyer' ne fonctionne pas.

Le nom d'un composant dans le code doit correspondre au texte que l'utilisateur voit, ou au moins contenir ce texte. Un bouton consistant en une image "envoyer" doit également contenir "envoyer" en tant que texte alternatif. Vous pouvez compléter le nom d'un composant mais pas le remplacer. Un lien 'lire plus' peut éventuellement être complété en 'lire plus sur l'article xyz'. Mais vous ne pouvez pas remplacer ce nom par un autre texte, par exemple avec aria-label = "article xyz".

2.5.4 Motion Actuation (A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

  • Supported Interface: The motion is used to operate functionality through an accessibility supported interface;
  • Essential: The motion is essential for the function and doing so would invalidate the activity.

Citation d'un utilisateur:

Cette fonction "shake to undo" (secouer pour annuler) n'est pas utile pour moi car j'utilise ma tablette avec ma voix. Heureusement, il existe également un bouton «Annuler».

Si une application détecte le mouvement de l'appareil ou de l'utilisateur pour exécuter une fonction, vous devez pouvoir effectuer la même fonction d'une autre manière. Par exemple en utilisant un bouton. Il doit également être possible d'arrêter la détection des mouvements.

4.1.3 Status Messages (AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Citation d'un utilisateur:

J'utilise un lecteur d'écran et j'essaie d'envoyer ce formulaire. Rien ne se passe et je n'obtiens aucun message d'erreur.

Les utilisateurs aveugles et malvoyants ne voient que la partie de l'écran où le focus se situe. Si quelque chose s'affiche à un autre endroit de l'écran sans que le focus ne s'y déplace, cette information ne sera pas vue. Si un message de statut important apparaît à l'écran, sans que le focus ne s'y déplace, il doit pouvoir être vu par une technologie d'assistance grâce à l'utilisation correcte de rôles et propriétés. Cela ne s'applique pas aux messages qui apparaissent dans une boîte de dialogue vers laquelle le focus se déplace.

Réagissez

Quelques pistes pour gérer l'accessibilité des documents

Sophie Schuermans le 19/02/2018

Vous avez décidé de vous attaquer à l'accessibilité de votre site web, et vous vous demandez si vous allez également devoir vous préoccuper de tous les documents téléchargeables. La réponse est oui , car pour le visiteur du site qui cherche une information, peu importe dans quel format vous avez décidé de publier l'information, l'important c'est qu'il puisse y avoir accès.

Dans le cas de sites existants, avec parfois des centaines ou des milliers de documents téléchargeables, cela peut sembler mission impossible. Voici quelques pistes pour y aller étape par étape.

Pour simplifier, je vais supposer que les documents téléchargeables sont des documents PDF.

Faites un tri

Essayez de déterminer quelles sont les grandes catégories de documents téléchargeables présents sur le site : publications scientifiques, comptes rendus de réunions, rapports annuels, heures d'ouverture du musée, menu du restaurant, infolettre...

Identifiez aussi qui publie ces documents (équipe communication, un fournisseurs externe, ...) et si possible au moyen de quelles applications (Word, open office, Indesign).

Mettez de côté les types de documents suivants:

  • documents redondants : si vous proposez un brochure destinée à l'impression mais dont le contenu est aussi disponible sur le site web, vous ne devez pas vous préoccuper de l'accessibilité du document PDF.
  • les archives: les documents anciens qui ne sont plus d'actualité
  • les documents externes : des documents que vous n'avez pas produits ou commandés vous-même

Concentrez-vous sur les documents qui restent.

Remplacez des documents téléchargeables par des pages web.

Pour chaque type de document, demandez-vous si ce serait une option de le publier sous forme de page web. Si vous avez un site web équipé d'un bon CMS, il est probablement beaucoup plus simple de publier l'info sous forme de page web, que de la rédiger dans une application telle que Microsoft Word, puis de la convertir en document PDF accessible.

C'est mieux pour l'internaute qui trouve l'information directement sur le site au lieu de devoir télécharger un document. C'est en général plus facile pour la personne qui rédige le document, car elle peut se focaliser uniquement sur le contenu.

Quelques exemples

  • Sur l'ancien site de l'ONEM, les informations de type feuille info étaient publiées sous forme de documents PDF. Sur le nouveau site, il s'agit simplement de pages web. Le nombre de pages n'a pas changé, mais au lieu de tomber sur une page proposant un lien de téléchargement, l'internaute tombe directement sur le contenu qui l'intéresse.
  • Sur le site de VVBAD, le magazine META était une page web contenant des liens vers les articles en PDF. A partir de cette année, ils ont décidé de mettre des liens vers des pages web pour chaque article.
  • Les textes de loi sont souvent publiés en format PDF en Belgique, mais il existe également la possibilité de les retrouver sous forme de page web sur le site du moniteur. Vous pouvez choisir de publier un lien vers la page web plutôt que de publier un document PDF.

A partir d'aujourd'hui ne publiez que des documents accessibles.

Si vous commencez aujourd'hui à ne publier que des documents accessibles, dans quelques années tous les documents utiles seront accessibles car les anciens documents vont petit à petit devenir obsolètes et disparaître de votre site.

Formez-vous pour apprendre à créer des documents PDF accessibles à partir de Microsoft Word ou Adobe InDesign.

Si vous faites appel à un prestataire externe, exigez également qu'il livre des documents accessibles.

Corrigez les documents anciens en commençant par les plus importants.

Lors de votre inventaire, vous avez identifié les documents les plus importants. Par exemple ceux qui sont les plus téléchargés. Dans la directive européenne on parle de documents 'nécessaires pour des processus administratifs actifs'. Par exemple, un document qui explique comment demander un congé parental.

Evaluez l'accessibilité de ces documents. Dans certains cas les problèmes seront faciles à résoudre, et vous pourrez à moindres frais faire les corrections et obtenir un bon résultat. Dans d'autres cas il se peut que vous deviez retravailler en profondeur le document d'origine.

Proposez un autre moyen d'obtenir l'info.

Pour tous les documents que vous n'aurez pas traités, donnez la possibilité au visiteur de vous contacter pour vous demander le contenu dans un format accessible.

Réagissez

La directive Européenne relative à l'accessibilité des sites web - résumé

Sophie Schuermans le 30/01/2017

La directive Européenne relative à l'accessibilité des sites web est entrée en vigueur le 22 décembre 2016. Cela signifie que tous les sites web et applications mobiles des organismes publics devront bientôt être accessibles.

Les organismes et les contenus concernés

La directive concerne les organismes du secteur public:

  • l'État,
  • les autorités régionales ou locales et
  • les organismes de droit public.

Les contenus visés par la directive sont:

  • sites web
  • applications mobiles
  • les documents téléchargeables sur les sites web
  • les contenus vidéo et audio intégrés sur les sites web

La directive s'appliquera donc par exemple à:

  • Tous les sites du gouvernement fédéral, du service public Wallon, de la région Flamande, de la région Bruxelloise et de la fédération Wallonie-Bruxelles
  • Les applications telles que tax-on-web, irisbox, mypension, myhandicap, etc.
  • Les sites de la sécurité sociale : ONEM, CAPAC, FEDRIS, ...
  • Les transports en commun : La STIB, De lijn, les TEC, la SNCB
  • Les administrations communales et les CPAS
  • Proximus

Exceptions

Certains contenus produits avant une certaine date sont exclus:

  • vidéo et audio publiés avant le 23/9/2020
  • documents publiés avant le 23 sept 2018 sauf si nécessaire pour un processus administratif actif
  • contenu d'extranet et intranets publiés avant le 23 sept 2019

Certains types de sites web ou de contenus sont exclus:

  • sites web des Opérateurs radio et TV
  • sites web de certaines ONG (services pas essentiels pour le public, ni spécifiquement pour les personnes handicapées)
  • sites web des écoles et crèches, sauf fonctions essentielles en ligne (par exemple inscription)
  • vidéo et audio en temps réel
  • Les cartes et services de cartographie en ligne (mais fournir infos essentielles pour les cartes destinées à la navigation)
  • contenus de tiers ni financés ni développés par l'organisme de service public, et pas sous son contrôle
  • reproductions de pièces de collections patrimoniales (par exemple texte manuscrit)
  • archives pas nécessaires pour les processus administratifs actifs

Les obligations des organismes publics

Accessibilité des sites web et apps mobiles

Les organismes publics doivent faire en sorte que leurs sites web et applications mobiles soient accessibles, c'est à dire conformes à la norme WCAG 2.0 niveau AA.

En réalité la directive fait référence à une norme harmonisée qui n'existe pas encore. En attendant une norme harmonisée, les sites devront être conformes à une norme européenne qui elle-même fait référence à WCAG 2.0 niveau AA.

Il n'y a pas de spécification technique équivalente à WCAG pour les applications mobiles. La commission Européenne doit en publier une pour le 23/12/2018.

Dates importantes

  • 23/9/2018:
    • Tous les sites web créés à partir de cette date devront être accessibles au plus tard le 23/9/2019.
    • Les documents publiés à partir de cette date devront être accessibles.
  • 23/9/2019 :
    • Les nouveaux sites (créés à partir du 23/9/2018) doivent être accessibles.
    • Tous les contenus d'extranets et d'intranets doivent être accessibles.
  • 23/9/2020 :
    • Tous les sites doivent être accessibles, même les plus anciens.
    • Les vidéos publiées à partir de cette date doivent être accessibles.
  • 23/6/2021 : Toutes les applications mobiles sont accessibles.

Déclaration d'accessibilité et mécanismes de contrôle

Les organismes publics devront publier une déclaration d'accessibilité, selon un modèle fourni par la commission Européenne. Cette déclaration devra contenir les infos suivantes :

  • Ce qui n'est pas accessible, et quelle alternative est prévue
  • Comment notifier l'organisme d'un problème accessibilité
  • Lien vers la procédure en cas de non respect

Obligations des états membres

Les états membres ont jusqu'au 23/9/2018 pour

  • transposer la directive
  • désigner un organisme pour effectuer les contrôles
  • désigner un organisme pour faire respecter la directive

Obligations de la Commission Européenne

La Commission est chargée de publier pour le 23/12/2018 quatre actes d'exécution :

  • spécification technique pour les applications mobiles
  • modèle de déclaration d'accessibilité
  • méthode de contrôle de conformité
  • modalités pour les comptes rendus des états membres à la commission

Conclusion

A partir du 23/9/2018 l'obligations d'accessibilité deviendra une réalité pour les nouveaux sites web publics. Les contenus des vidéos, les sites plus anciens et les applications mobiles suivront rapidement.

En tant qu'organisme public, cela vous donne le temps de vous organiser, mais il ne faut pas attendre septembre 2018 pour s'y mettre. Quelques pistes pour atteindre plus facilement les objectifs de la directive:

  • Former et sensibiliser les personnes concernées
  • Inclure l'accessibilité dans le cahier des charges (site web, brochure PDF, vidéo, app,...)
  • Choisir des prestataires qui ont déjà de l'expérience en accessibilité numérique
  • Y aller progressivement, en commençant par ce qui vous semble le plus facile.

Si vous avez des questions, n'hésitez pas à nous contacter.

2 réactions

HTML5 outline n'est pas supporté

Sophie Schuermans le 03/06/2016

Traduction de l'article en néerlandais HTML5 outline algorithm. Mis à jour le 2 juin 2016

En résumé

  • Continuez à utiliser une hiérarchie correcte de titres ( <h1>, <h2>, <h3>,...) pour structurer vos pages web, même lorsque vous utilisez des éléments sectionnants.
  • Ne vous appuyez pas sur le nouvel outline HTML5 qui calcule automatiquement le niveau de titre sur base de l'imbrication des éléments sectionnants (<section>, <nav>,<aside> et <article>).

Les personnes qui n'ont pas de vue d'ensemble de leur écran, comme les personnes aveugles ou malvoyantes, peuvent utiliser un logiciel qui lit tout ce qui est affiché à l'écran. Ce logiciel, appelé lecteur d'écran, fait plus que simplement lire le contenu affiché. Il annonce entre autres les titres, les listes et les tableaux. Lorsqu'un lecteur d'écran vocalise un titre, le lecteur d'écran annonce également le niveau du titre. Par exemple sur notre page Eviter le spam sans captcha un lecteur d'écran lira 'Eviter le spam sans captcha titre de niveau 1'. Un peu plus bas le sous-titre 'pas de captcha' est lu 'Pas de captcha titre de niveau 2'. Et ainsi de suite.

indication des niveaux de titre dans l'article sur les captcha

Cette information est cruciale pour ceux qui ne peuvent pas (ou à peine) voir l'écran. Les niveaux de titre permettent de mieux comprendre la structure de la page. Le lecteur d'écran permet également de sauter d'un titre à l'autre en utilisant un raccourci clavier ('t' pour 'titre') ou d'obtenir un liste de tous les titres (outline) de la page. La capture d'écran ci-dessous montre une liste de titres obtenue avec le lecteur d'écran VoiceOver sur Mac.

liste de titres obtenue avec VoiceOver

C'est pour cela que les directives d'accessibilité demandent d'utiliser une structure de titres logique. C'est essentiel pour les visiteurs ayant une déficience visuelle. Cela favorise également le référencement naturel.

HTML5 a introduit de nouveaux éléments qui permettent de mieux structurer les pages web. Ce sont les éléments sectionnants, comme par exemple <section>, <nav>,<aside> et <article>.

En HTML4 il était toujours nécessaire d'indiquer explicitement les niveaux de titre. Le titre principal de la page est un h1, un sous-titre un h2 etc. Si vous utilisez les nouveaux éléments sectionnants proposés par HTML5, vous pouvez (mais n'êtes pas obligé) utiliser toujours h1 en début de section. C'est l'imbrication des éléments sectionnants qui détermine la structure du document, et donc les niveaux de titre (voir l'algorithme d'outline d'HTML5). Pour chaque niveau d'imbrication le niveau de titre est incrémenté de 1. Un h1 qui se trouve à l'intérieur d'un élément section imbriqué dans un autre élément section devient automatiquement un h2. Si vous utilisez un h1 dans un élément sectionnant qui est imbriqué au 3ème niveau, il devient un h3 dans l'outline, etc.

En théorie

Ci-dessous, un exemple (source: W3C) avec une hiérarchie de titres traditionnelle.

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

L'outline des titres devient::

<h1>Apples</h1>
<h2>Taste</h2>
<h3>Sweet</h3>
<h2>Color</h2>

La spécification HTML5 permet de n'utiliser que des h1:

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h1>Taste</h1>
  <p>They taste lovely.</p>
  <section>
   <h1>Sweet</h1>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

Grâce à l'utilisation de sections ce sera interprété exactement de la même manière:

<h1>Apples</h1>
<h2>Taste</h2>
<h3>Sweet</h3>
<h2>Color</h2>

En théorie cet algorithme devrait faciliter la vie d'un développeur, à conditions qu'il utilise un hiérarchie correcte de sections (et autres éléments sectionnants comme <nav>, <aside> et <article>). Mais est-ce que cela donne de bons résultats lors d'une lecture avec un lecteur d'écran? Est-ce que les personnes aveugles et malvoyantes vont entendre des niveaux de titre corrects?

En pratique

L'exemple ci-dessus ("apples") utilisant des éléments <section> et uniquement des h1 donne les résultats suivants pour les lecteurs d'écrans les plus courants:

logo NVDA NVDA
  • version 2016.1 avec IE11 et FireFox 46: pas de support, ne lit que des h1
logo Supernova Supernova
  • version 13.59 avec Internet Explorer 11: pas de support, ne lit que des h1
logo VoiceOver VoiceOver
  • OS X 10.11.5 (El Capitan) avec Safari 9.1.1: pas de support, ne lit que des h1
logo Jaws Jaws
  • versions 15, 16 et 17 avec IE11 et Firefox 46: pas de support, ne lit que des h1

Conclusions du test:

Il n'y a pas de support pour l'outline HTML5 de la part des principaux lecteurs d'écran. Si vous utilisez des éléments sectionnants en combinaison avec des h1 uniquement, la structure des pages ne sera pas visible pour la majorité des visiteurs utilisant un lecteur d'écran. La spécification HTML5.1 déconseille de compter sur l'algorithme d'outline pour construire la hiérarchie de titres

There are currently no known implementations of the outline algorithm in graphical browsers or assistive technology user agents, although the algorithm is implemented in other software such as conformance checkers. Therefore the outline algorithm cannot be relied upon to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure.
Réagissez