Maintenant que nous savons créer la structure de notre site, nous allons nous intéresser aux interactions qui la composent. Dans le chapitre dédié au menu de navigation de la partie précédente, nous avons touché du doigt les interactions.
Dans cette partie, nous allons nous attarder sur :
les formulaires (ainsi que leur validation) ;
les fenêtres modales ;
les carrousels ;
les techniques CSS et des outils dédiés à l’accessibilité.
Nous allons pouvoir mettre à profit nos connaissances nouvelles en ARIA pour rendre nos interactions accessibles. C’est parti !
Découvrez l’importance de l’accessibilité dans le feedback
L’impact des interactions sur l’accessibilité
Comme vous l’avez peut-être vu dans le précédent cours dédié à l’accessibilité pour les chefs de projet et les designers, il existe de nombreuses manières d’interagir sur un site. On peut, par exemple, penser à :
un menu de navigation qui s’ouvre et se ferme (ce que nous avons vu dans ce cours) ;
une fenêtre modale qui s’ouvre lorsqu’on clique sur un bouton ;
des indicateurs d’erreurs quand on complète mal un formulaire.
Dans l’ensemble des cas cités ci-dessus, nous allons devoir penser aux différents publics susceptibles d’utiliser notre site web. Il va, par exemple, nous falloir :
mettre en place des feedbacks visuels (quand une donnée d’un formulaire est correcte ou erronée) ;
gérer les attributs ARIA pour donner des informations complémentaires vis-à-vis d’un champ de formulaire ;
masquer, via les attributs ARIA, la présence d'une fenêtre modale ;
gérer un carrousel ainsi que ses contrôles (tant au clavier qu’à la souris).
Bien entendu, une partie du travail sera réalisée par le designer ainsi que le chef de projet. Cela dit, en tant que développeur, vous devrez traduire ces attentes en code. :)
Pourquoi cela peut sembler compliqué ?
Avant de vous parler des solutions, sachez que cette partie est plus complexe que celle concernant la structure de la page HTML. En effet, vous ne gérez plus l'ossature de votre site, mais des éléments dynamiques.
Autrement dit, vous gérez des éléments qui peuvent apparaître ou disparaître à l’écran et/ou être contrôlés par l’utilisateur.
D’où l’importance de votre travail :
avec votre designer, puisque c’est cette personne qui va vous fournir les maquettes ;
avec votre chef de projet, puisque que vous allez pouvoir réfléchir sur la mise en place d’un plan d’accessibilité.
Dans le “plan de taggage” (ou plan de marquage), vous allez utiliser un document pour faciliter l’analyse de l’audience de votre site (où est-ce que vos utilisateurs cliquent le plus, etc.)
Le plan d’accessibilité permet de décrire quels sont les états et balises/attributs attendus pour chaque élément de votre site : les boutons, les formulaires, les images, etc.
Nous verrons ci-dessous les attributs ARIA liés aux interactions (rassurez-vous, vous en connaissez déjà certains ;) ), avant de nous attaquer aux technologies dont vous aurez besoin.
Tirez parti d’ARIA pour informer l’utilisateur sur les interactions
Les attributs ARIA au service de l’interaction
Dans la partie précédente, nous avons vu que les attributs ARIA peuvent être utilisés pour décrire un élément. En plus de cette capacité, ces attributs peuvent aussi décrire l’état d’un élément.
Si vous vous souvenez du chapitre dédié à la navigation et plus précisément au menu déroulant, vous avez pu voir que les attributs ARIA permettaient aussi de montrer si un élément était ouvert ou fermé.
Sachez que les attributs ARIA vont nous permettre d’aller plus loin. En effet, nous allons pouvoir utiliser ces derniers :
pour indiquer comment ouvrir et fermer une fenêtre modale (et indiquer si celle-ci est ouverte ou fermée).
pour indiquer si un menu de navigation est ouvert ou fermé, et où et comment l’ouvrir.
Les technologies dont vous aurez besoin
Comme vous le savez peut-être déjà, le HTML n’est pas un langage de programmation mais un langage de “structuration”.
Autrement dit, quand vous allez vouloir ouvrir une fenêtre modale ou un menu dropdown, vous allez utiliser le JavaScript pour ouvrir cette fenêtre.
De la même façon, quand vous allez compléter un formulaire, bien que le HTML puisse faire des vérifications de façon native, vous allez passer par une vérification via le JavaScript, puis côté backend (via du PHP, par exemple).
Les langages de programmation comme Javascript et PHP permettent de modifier les attributs et balises HTML. Autrement dit, quand l’état du site va changer, nous allons pouvoir répercuter ces informations coté HTML. Cela permettra aux utilisateurs ayant des technologies d'assistance de bien comprendre les changements apportés sur le site.
En résumé
Le HTML est là pour structurer vos pages. Ce n’est pas ce langage qui va permettre de mettre en place les interactions.
Cela dit, le HTML va indiquer l’état de votre page. Par exemple, si un menu déroulant apparaît à l’écran, et comment le fermer.
Essayez de penser vos interactions le plus en amont possible. C’est d’abord le travail du designer (qui renseigne ça dans la maquette), puis du chef de projet (qui traduit ça en features).
Dans ce chapitre, nous avons revu rapidement les tenants et aboutissants de la gestion des interactions. Nous allons maintenant attaquer un chapitre très important : les formulaires et l’accessibilité.
