accessiweb html5/aria séminaire accessiweb juin 2013
TRANSCRIPT
AccessiWeb HTML5/ARIAAccessiWeb HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW 2.2 n'est pas adapté à HTML 5
Les différences de fond et les évolutions sont trop nombreuses pour porter AW 2.2 vers HTML 5
HTML5 supprime ou modifie des éléments requis par AW 2.2• Par exemple summary pour les tableaux,
longdesc pour les images• Outline pour le titrage…
La notion d’alternative et de compatibilité pour Javascript telle que définie par AW 2.2 n’est pas adaptée à HTML 5
AW 2. ne prend pas en charge l’API ARIA
Juin 2012Préparation
Novembre 2012
PropositionAdaptation
Décembre2012
PréparationRéférentielMars
2013PublicationAdaptation
Juin 2013Référentiel
HTML5 / ARIA
Séminaire AccessiWeb Juin 2013
Généralités
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA- Modification de la nomenclature (niveaux : A, AA, AAA !)- Très peut de nouveaux critères (on reste à 133 critères)- Les nouveaux éléments sont implémentés au niveau des tests - Pris en charge d'ARIA chaque fois que nécessaire :
- Présence/pertinence des rôles ARIA nécessaires- Test de la restitution AT chaque fois que nécessaire
- Création de "notes techniques" chaque fois que nécessaire liées aux critères sur le même modèle que le glossaire
- Création d'une "base de référence" pour la compatibilité avec l'accessibilité
RéférentielAW HTML5
Glossaire NotesTechniques
Glossaire NotesTechniques
Base deréférence
Séminaire AccessiWeb Juin 2013
Quelques exemples…
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
Images
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
Images
AW HTML5/ARIA
- Prise en charge de SVG et CANVAS
- Prise en charge ARIA- propriété aria-label pour labelliser une image SVG- Role "présentation" pour une image de décoration (interdiction)
- Création d'un critère spécifique sur les images légendées- Figure- Figcaption - Role "group"
- Prise en charge de title sur l'élément IMG - Obligatoirement identique au alt
- Test de restitution des alternatives implémentée dans SVG via aria-label ou <desc>
Séminaire AccessiWeb Juin 2013
Images
Critère 1.1 [A] Chaque image a-t-elle une alternative textuelle ?
• Test 1.1.4 : Chaque image vectorielle (balise <svg>) vérifie-telle une de ces conditions ? o La balise svg possède un attribut aria-label o Un élément <desc> est présent
Note technique
A l'exception de svg, l'utilisation des attributs aria-label et aria-labelledby permettant de créer une alternative ou de lier l'image à un passage de texte faisant office d'alternative ne peuvent pas être utilisés par manque de support des technologies d'assistance.
La spécification SVG préconise d'utiliser un élément <title> pour la description "courte" et un élément <desc> pour la description longue. Actuellement seul l'élément <desc> est correctement restitué par les technologies d'assistance. L'usage de l'élément <title> est donc considéré comme incompatible avec l'accessibilité.
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
Critère 1.3 [A] Pour chaque image porteuse d'information ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers) ?
•Test 1.3.1 : Chaque image porteuse d'information (balise img) ayant un attribut alt vérifie-t-elle ces conditions (hors cas particuliers) : o Le contenu de l'attribut alt est pertinent o S'il est présent le contenu de l'attribut title est identique au contenu de l'attribut alt
oTest 1.3.6: Chaque image vectorielle porteuse d'information (balise svg) et possédant une alternative vérifie-t-elle une de ces conditions (hors cas particuliers)? o La balise svg possède un attribut aria-label dont le contenu est pertinent et identique à l'attribut title s'il est présent o La balise svg possède un élément <desc> dont le contenu est pertinent et identique à l'attribut title de la balise svg s'il est présent o Un lien adjacent permet d'accéder à une alternative dont le contenu est pertinent et identique à l'attribut title de la balise svg s'il est présent
• Test 1.3.7: Pour chaque image vectorielle porteuse d'information (balise svg) et possédant une alternative, cette alternative est-elle correctement restituée par les technologies d'assistance ?
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
Critère 1.6 [A] Chaque image porteuse d'information a-t-elle, si nécessaire, une description détaillée ?
•Test 1.6.5: Chaque image vectorielle (balise <svg>) qui nécessite une description détaillée vérifie-t-elle une de ces conditions ? o Il existe un attribut aria-label contenant une référence à une description détaillée adjacente à l'image vectorielle o Il existe un élément <desc> contenant une référence à une description détaillée adjacente à l'image vectorielle o Il existe un élément <desc> contenant la description détaillée o Il existe un lien adjacent (via une url ou une ancre) permettant d'accéder au contenu de la description détaillée
AW HTML5/ARIA
• Test 1.6.6: Pour chaque image vectorielle (balise <svg>) qui implémente une référence à une description détaillée adjacente via un attribut aria-label ou un élément <desc>, cette référence est-elle correctement restituée par les technologies d'assistance ?
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
<figure> <img src="pic.jpg"> <figcaption> Légende de l'image </figcaption> </figure>
<figure role="group" > <img src="pic.jpg" alt="photo 1" > <figcaption> Légende de l'image (photo 1) </figcaption> </figure>
Spécification HTML5 Fallback note WCAG
L'atrribut ARIA role="group" permet de créer une relation explicite entre l'image et sa légende
La présence d'un "label" (nom de l'image) dans l'alternative permet de créer une relation implicite entre l'image et sa légende
Prise en charge de <figure> et <figcaption>
Séminaire AccessiWeb Juin 2013
Critère 1.10 [A] Chaque légende d'image est-elle, si nécessaire, correctement reliée à l'image correspondante ?
AW HTML5/ARIA
• Test 1.10.1 : Chaque image légendée (balise img ou input de type image associée à une légende adjacente) vérifie-telle, si nécessaire, ces conditions ? o L'image (balise img) et sa légende sont contenues dans un élément figure o L'élément figure possède un attribut role="group" o Le contenu de l'attribut alt de l'image contient une référence à la légende adjacente o L'attribut title de l'image s'il est présent, est strictement identique au contenu de l'attribut alt
Note technique (extrait)
Bien que recommandé par HTML5, la note WCAG stipule que le title ne peut pas être utilisé pour "labelliser" l'image.
Les attributs aria-label, aria-labelledby et aria-describedby ne peuvent pas être utilisés actuellement par manque de support par les technologies d'assistance.
Séminaire AccessiWeb Juin 2013
CadresCouleurs
AW HTML5/ARIA
Pas de changement
Séminaire AccessiWeb Juin 2013
Multimédia
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
Critère 4.3 [A] Chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, des sous-titres synchronisés (hors cas particuliers) ?
AW HTML5/ARIA
• Test 4.3.2: Pour chaque média temporel synchronisé pré-enregistré possédant des sous-titres synchronisés diffusés via un élément <track>, l'élément <track> possède-t-il un attribut kind="captions"
Multimédia
- Peu de changements- Prise en charge de VIDEO et AUDIO par le glossaire- Prise en charge de <track> chaque fois que nécessaire
Séminaire AccessiWeb Juin 2013
Tableaux
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Tableaux
- Abandon du support de SUMMARY
- Nouvelle définition de glossaire "tableaux de données complexe"
- Restriction de l'utilisation des techniques de summary HTML5 aux tableaux de données complexe
- Support du rôle "présentation" pour déclarer un tableau de mise en forme
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Critère 5.1 [A] Chaque tableau de données complexe a-t-il un résumé ?
• Test 5.1.1 : Pour chaque tableau de données complexe (balise table) un résumé est-il disponible dans la balise <caption> ?
Note technique
La spécification propose plusieurs méthodes pour lier un résumé à un tableau (tableau lié à un passage de texte avec aria-describedby, tableau groupé via figure avec le résumé en texte adjacent, tableau groupé avec figure avec le résumé dans un élément figcaption, résumé dans un élément details dans l'élément caption).
Ces méthodes n'ont pas un support suffisant pour être utilisées actuellement.
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIACritère 5.3 [A] Pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ?
• Test 5.3.1 : Chaque tableau de mise en forme vérifie-t-il ces conditions ? o le contenu linéarisé reste compréhensible o la balise <table> possède un attribut role="presentation"
La spécification recommande de mapper un tableau de mise en forme avec le rôle "présentation".
"If a table is to be used for layout it must be marked with the attribute role="presentation" for a user agent to properly represent the table to an assistive technology and to properly convey the intent of the author to tools that wish to extract tabular data from the document."
Séminaire AccessiWeb Juin 2013
Liens
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
Liens
AW HTML5/ARIA
Html 5 autorise l'utilisation d'éléments de type block dans un lien (A HREF).Ce type de lien est supporté par toutes les AT mais peut causer des problèmes de restitution.Cette utilisation est à éviter
Problème potentiels NVDA /JAWS : répétition de liens pour chaque élément de
contenus sur certaines fonctionnalités VOICE OVER : texte répétés plusieurs fois de suite JAWS : disparition des titres via la liste des titres de la page
Aucun changement
Séminaire AccessiWeb Juin 2013
Scripts
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Scripts
- Abandon de l'obligation à des alternatives Javascript
- Obligation de respecter les motifs de conception ARIA
- Obligation de respecter les interactions clavier définit par les motifs de conception ARIA- Exigence réduite aux touches principales
- Obligation de respecter les recommandations de la spécification et de la note technique "Using ARIA in HTML" sur :
- Les surcharges de role (par exemple <NAV role="NAVIGATION">
- Les restrictions de modification du role natif HTML d'un élément (tableau de référence de la note sur ARIA)
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIACritère 7.1 [A] Chaque script est-il, si nécessaire, compatible avec les technologies d'assistance ?
• Test 7.1.3 : Chaque script qui génère ou contrôle un composant d'interface via des rôles, des états ou des propriétés définis par l'API ARIA vérifie-t-il, si possible, une de ces conditions ? o Le composant d'interface est conforme au motif de conception défini par l'API ARIA o Un composant d'interface présent sur la page, permettant d'accéder aux mêmes fonctionnalités, est conforme au motif de conception défini par l'API ARIA o Une alternative accessible permet d'accéder aux mêmes fonctionnalités.
• Test 7.1.6: Pour chaque script qui génère ou contrôle un composant d'interface via des rôles, des états ou des propriétés définis par l'API ARIA respecte-t-il une de ces conditions : o Le composant d'interface est correctement restitué par les technologies d'assistance o Une alternative accessible permet d'accéder aux mêmes fonctionnalités.
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIACritère 7.3 [A] Chaque script est-il contrôlable par le clavier et la souris (hors cas particuliers) ?
• Test 7.3.4 : Chaque composant d'interface implémenté via un rôle défini par l'API ARIA et correspondant à un motif de conception respecte-t-il, si possible, ces conditions ? o Les interactions au clavier sont conformes au comportement défini par le motif de conception pour les touches Escape, Barre d'espace, Tabulation et Flèches de direction au moins o Un composant d'interface présent sur la page, permettant de réaliser la même action, possède des interactions au clavier conformes au comportement défini par le motif de conception, pour les touches Escape, Barre d'espace, Tabulation et Flèches de direction au moins o Une alternative permettant d'accéder aux mêmes fonctionnalités est contrôlable par le clavier et à la souris.
Séminaire AccessiWeb Juin 2013
Eléments Obligatoires
AW HTML5/ARIA
Pas de changement
Séminaire AccessiWeb Juin 2013
Structuration de l'information
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Structuration de l'information
- Prise en charge des nouveaux éléments- HEADER, NAV, MAIN, FOOTER rendus obligatoires pour structurer le document
- Test de cohérence de l'OUTLINE (utilisation des éléments sectionnants)
- Interdiction de l'utilisation exclusive de H1, obligation d'utiliser des titres Hx cohérent
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA• Critère 9.1 [A] Dans chaque page Web, l'information est-elle structurée par l'utilisation
appropriée de titres ?
• Test 9.1.1 : Dans chaque page Web, y a-t-il un titre de niveau 1 (balise h1 ou balise possédant un role ARIA "heading" associé à une propriété aria-level="1") ?
• Test 9.1.2 : Dans chaque page Web, la hiérarchie entre les titres (balises h ou balise possédant un role ARIA "heading") est-elle pertinente ?
• Test 9.1.3 : Dans chaque page Web, chaque titre (balises h ou balise possédant un role ARIA "heading") nécessaire à la structure de l'information est-il présent ?
• Test 9.1.4 : Dans chaque page Web, chaque titre (balises h ou balise possédant un role ARIA "heading") est-il pertinent ?
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Test de cohérence de l'outline
<body>
<nav> <article> <aside>
<section>
<H2>
<H2>
<H3>
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIACritère 9.2 [A] Dans chaque page Web, la structure du document est-elle cohérente ?
• Test 9.2.1 : Dans chaque page Web, la structure du document vérifie-t-elle ces conditions ? o La zone d'en-tête principale est structurée via une balise <header> o Les zones de navigation principales et secondaires sont structurées via une balise <nav> o La balise <nav> est réservée à la structuration des zones de navigations principales et secondaires o La zone de contenu principal est structurée via une balise <main> o La structure du document utilise une balise <main> unique o La zone de pied-de-page est structurée via une balise <footer>
• Test 9.2.2: dans chaque page web l'arborescence du document est-elle cohérente ?
Séminaire AccessiWeb Juin 2013
Présentation de l'information
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Présentation de l'information
- Prise en charge de aria-hidden et de hidden- Test de cohérence de l'utilisation de aria-hidden pour interdire la vocalisation- Test de cohérence de l'utilisation de hidden en relation avec le statut visible ou
caché des propriétés CSS display:none et visibility:visible
Critère 10.13 [A] Pour chaque page Web, les textes cachés sont-ils correctement restitués par les technologies d'assistance ?
• Test 10.13.2 : Dans chaque page Web, chaque texte caché qui utilise une propriété ARIA aria-hidden vérifie-t-il une de ces conditions ? o Le texte n'a pas vocation à être restitué par les technologies d'assistance o La valeur de la propriété ARIA aria-hidden est cohérente avec l'état visible ou caché du texte
Séminaire AccessiWeb Juin 2013
Formulaire
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Formulaire
- Prise en charge des techniques de labellisation ARIA pour les champs et les boutons :- aria-label- aria-labelledby
- Prise en charge des messages automatiques d'aide à la saisie ou de gestion des erreurs utilisés par les nouveaux types de champs de formulaire HTML5
- Prise en charge de aria-required et de required pour les saisies obligatoires
- Prise en charge de aria-describedby pour lier un message d'aide à la saisie ou d'erreur
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIACritère 11.1 [A] Chaque champ de formulaire a-t-il une étiquette ?
• Test 11.1.1 : Chaque champ de formulaire, vérifie-t-il une de ces conditions ? o Le champ de formulaire possède un attribut title o Une étiquette (balise label) est associée au champ de formulaire o Le champ de formulaire possède une propriété aria-label o Le champ de formulaire possède un attribut aria-labelledby référençant un passage de texte identifiéCritère 11.10 [A] Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ?• Test 11.10.1 : Pour chaque formulaire, les champs obligatoires vérifient-ils une de ces conditions ? o L'indication de champ obligatoire est indiquée dans l'étiquette (balise label, attribut title, propriété aria-label, texte lié via la propriété aria-labelledby) du champ de formulaire o L'indication de champ obligatoire est indiquée par un passage de texte avant le champ de formulaire o L'indication de champ obligatoire est indiquée via un attribut required o L'indication de champ obligatoire est indiquée via la propriété ARIA aria-required o L'indication de champ obligatoire est indiquée par un passage de texte lié par la propriété ARIA aria-describedby
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA• Test 11.10.4 : Pour chaque formulaire, les erreurs de saisie vérifient-elle une de ces conditions ? o L'erreur de saisie est indiquée dans l'étiquette (balise label, attribut title, propriété ARIA aria-label, texte lié via la propriété ARIA aria-labelledby) du champ de formulaire o L'erreur de saisie est indiquée par un passage de texte avant le champ de formulaire o Le champ de formulaire possède un type qui produit de manière automatique un message d'erreur de saisie o L'erreur de saisie est indiquée par un passage de texte lié par la propriété ARIA aria-describedby
• Test 11.10.5 : Chaque erreur de saisie qui utilise la propriété ARIA aria-label doit être accompagnée d'un passage de texte avant le champ du formulaire, cette règle est-elle respectée ?
Séminaire AccessiWeb Juin 2013
Navigation
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Navigation
- Prise en charge des role aria landmark, obligation d'utilisation de - banner, navigation, main, contentinfo, search
Critère 12.10 [A] Dans chaque page Web, les groupes de liens importants (menu, barre de navigation...) et la zone de contenu sont-ils identifiés ?
• Test 12.10.4 : Dans chaque page Web, la structure du document vérifie-t-elle ces conditions ? o La zone d'en-tête de la page possède un rôle ARIA "banner" o Le menu de navigation principal possède un rôle ARIA "navigation" o La zone de contenu principal possède un rôle ARIA "main" o La zone de pied-de-page possède un rôle ARIA "contentinfo" o Le champ de saisie du moteur de recherche sur le site possède un rôle "search" o Les rôles "banner","navigation","main","contentinfo" et "search" sont uniques dans la page.
Séminaire AccessiWeb Juin 2013
Consultation
AW HTML5/ARIA
Pas de changement
Séminaire AccessiWeb Juin 2013
Base de référence
AW HTML5/ARIA
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Base de référence
L'établissement de la base de référence nécessaire pour établir qu'un dispositif HTML5/ARIA est "compatible avec l'accessibilité" est établie sur la base de la collecte des données disponibles sur les usages des Technologies d'Assistance impactées.
1. Quatre technologies d'assistances (NVDA, JAWS, WINDOW-EYES, VOICE OVER) représentent 84% des usages "habituels".2. Deux systèmes d'exploitation (WINDOWS XP+, IOS/OSX) couvrent plus de 95% des usages3. Trois navigateurs (INTERNET EXPLORER, FIREFOX, SAFARI) couvrent plus de 90% des usages par les utilisateurs de technologies d'assistance.4. INTERNET EXPLORER 8 ne présente pas de support suffisant et ne peut pas être considéré.Sur cette base il est apparu que l'on pouvait considérer (en attendant une généralisation du support de l'accessibilité par l'ensemble des technologies d'assistance, des systèmes d'exploitation et des navigateurs) que l'ensemble des éléments définis ci-dessus permettait de couvrir environ 80% des usages habituels des utilisateurs impactés.
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Base de référence
Technologies d'assistance d'usage habituel
Source : Enquête WEBAIM 2012
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Base de référence
La base de référence est établie en tenant compte de plusieurs facteurs :•La proportion d'usage des technologies d'assistance :Quatre d'entre-elles (NVDA, JAWS, VO, Windows Eyes) couvrent 84% des usages (Webaim survey #4 – 2012)•La proportion d'usage des systèmes d'exploitation :Deux d'entre eux (Windows et OSX) couvrent plus de 95% des usages•L'usage de la plateforme Linux est confidentiel et distribué sur un grand nombre de versions.•La proportion d'usage des Navigateurs et de leurs versions
Trois d'entre eux sont gratuits et mis à jour automatiquement (Chrome, Firefox et Safari), Firefox est disponible pour toutes les versions de Windows (nécessite pour XP une mise à jour gratuite du service pack 3).
Internet Explorer 9 et 10 sont incompatibles avec windows XP (qui représente 41% de la base installée de windows), Internet Explorer 8 n'ayant aucun support HTML5/ARIA ne peut pas être pris en compte.
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Base de référence
Les différentes combinaisons possibles qui peuvent être considérées
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Base de référence
Pour qu'un dispositif HTML5/ARIA ou son alternative soit considéré comme compatible avec l'accessibilité il faut qu'il soit pleinement fonctionnel, en termes de restitution et de fonctionnalités, sur au moins une des combinaisons suivantes :
Combinaison 1 :
- NVDA + Firefox- JAWS + (Firefox ou IE9 +)- VOICE OVER + Safari
Combinaison 2 :
- JAWS + Firefox- NVDA + (Firefox ou IE9 +)- VOICE OVER + Safari
Combinaison 3 :
- JAWS + Firefox- WINDOW EYES + (Firefox ou IE9+)- VOICE OVER + Safari
Combinaison 4 :
- WINDOW EYES + Firefox- JAWS + (Firefox ou IE9 +)- VOICE OVER + Safari
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Base de référence
Les règles suivantes doivent également être respectées
1. L'ensemble des dispositifs HTL5/ARIA ou leurs alternatives doivent être pleinement fonctionnels, sur l'ensemble des pages du site, sans nécessiter de changement de technologie d'assistance en cours d'utilisation
2. Lorsque des alternatives à des dispositifs HTML5/ARIA sont proposées elles ne doivent pas nécessiter la désactivation d'une technologie (par exemple Javascript ou le plugin flash) sauf s'il s'agit d'une fonctionnalité proposé par le site lui-même.Par exemple
• le site met à disposition une version alternative conforme pleinement fonctionnelle sans le recours aux technologies dont l'usage est non-compatible avec l'accessibilité.
• Le site met à disposition une fonctionnalité de remplacement des dispositifs HTML5/ARIA par des dispositifs alternatifs compatibles.
Séminaire AccessiWeb Juin 2013
AW HTML5/ARIA
Base de référence
3. Un moyen est mis à disposition des utilisateurs de technologies d'assistance pour signaler les problèmes rencontrés et obtenir, via un dispositif de compensation, les informations qui seraient rendues indisponibles 4. Si une déclaration de conformité est établie elle doit comporter la liste des technologies d'assistance avec lesquelles les dispositifs HTML5/ARIA ont été testés et les résultats de ces tests (par exemple "supporté", "non supporté", "supporté partiellement") au moins.
Séminaire AccessiWeb Juin 2013
Roadmap
AW HTML5/ARIA
Juillet 2013publication d'une version "expérimentale" publique sur le site AccessiWeb
Octobre 2013publication de la version définitive
Merci de votre attention
Merci de votre attention
Séminaire AccessiWeb Juin 2013
Merci à :
Armony Altinier - Aurélien Levy – Frédéric Halna - Gilles Chagnon – Laurent Denis – Olivier Nourry - Marc-Etienne Vargenau – Patrice Bourlon - Philippe Vayssière - Romain Gervois - Sébastien Delorme - Sylvie Duchateau - Tanguy Lohéac - Victor Brito