Player

L'accessibilité globale proposée par un Player est de deux natures : l'accessibilité de l'interface : la barre d'outils doit être manipulable sans souris, les éléments qui la composent suffisamment contrastés, et toute l'interface doit interagir correctement avec les aides techniques le support de fonctionnalités avancées : capacité à exploiter des flux additionnels (sous-titrage, audio-description) qui permettront d'accroitre l'accessibilité du flux de données principal.

Fieldset

le libellé "" devrait être le libellé du <legend> d'un <fieldset> qui englobe .
    

Pop-in

V1 :

Les régles pour qu'une fenêtre modale soit accessible : Au lancement de cette nouvelle fenêtre, l'utilisateur doit être informé de cette situation, A l'ouverture de la fenêtre modale le focus doit être placé sur un élément situé au tout début de la fenêtre modale, les éléments situés sous la fenêtre modale ne doivent plus être vocalisés, on doit pouvoir boucler sur les éléments "focusables" que contient la fenêtre modale par la touche tab, le contenu de la fenêtre modale doit être inséré immédiatement aprés l'élément qui en a déclenché l'affichage, on doit pouvoir refermer la fenêtre modale par un lien ou bouton d'action ainsi que par la touche "Echap", lorsque l'on referme la fenêtre modale on doit se retrouver positionné au niveau de l'élément qui en a provoqué l'affichage en fonction de son contenu, il vaudrait mieux que le contenu de la fenêtre modale soit ajouté dans le dom au moment de l'affichage plutôt que simplement masqué par le CSS

V2 :

Les régles pour qu'une fenêtre modale soit accessible : A l'ouverture de la fenêtre modale le focus doit être placé sur un élément situé au tout début de la fenêtre modale, les éléments situés sous la fenêtre modale ne doivent plus être vocalisés, on doit pouvoir boucler sur les éléments "focusables" que contient la fenêtre modale par la touche tab ou en marche arriére par maj tab sans sortir de la fenêtre modale on doit pouvoir refermer la fenêtre modale par un lien ou bouton d'action ainsi que par la touche "Echap", lorsque l'on referme la fenêtre modale on doit se retrouver positionné au niveau de l'élément qui en a provoqué l'affichage en fonction de son contenu, il vaudrait mieux que le contenu de la fenêtre modale soit ajouté dans le dom au moment de l'affichage plutÙt que simplement masqué par le CSS

Aria-expanded

Il doit indiquer l'état de l'élément dont il pilote l'ouverture (ouvert/fermé) au moyen d'un attribut aria-expanded, qui aura la valeur "false" lorsque l'élément est ouvert, et "true" lorsque l'élément est fermé. Il faudra également qu'il soit relié à l'élément dont il pilote l'ouverture au moyen d'un attribut "aria-controls" qui reprendra la valeur de l'attribut "id" de cet élément.

Type de document

      Bien que cela ne soit pas obligatoire, il est tout de même recommandé d'employer un doctype HTML5 afin de pouvoir mettre en úuvre de faÁon valide toutes les composantes actuelles du HTML
    

200%

Le test se fait sous Firefox, en cochant "Affichage / Zoom / Zoom texte seulement", puis en grossissant le texte de six "crans" (ctrl ++ ou ctrl molette). Il ne faut pas que des éléments dépassent de leur container, ou soient tronqués.
    

labelledby etc

Le champ de saisie du formulaire () doit avoir un attribut "id" dont la valeur est unique dans la page, et le libellé doit être présenté dans un élément <label> dont l'attribut "for" reprendra la valeur de l'attribut "id" du champ de formulaire. Le champ de formulaire à un attribut "aria-label" dans lequel on placera le libellé qui sera l'étiquette du champ. Le container du libellé (par exemple un <span> ou un <p>), doit avoir un attribut "id" ayant une valeur unique dans la page. L'élément de formulaire aura un attribut "aria-labelledby" dont le contenu reprendra celui de l'attribut "id" du container du libellé. Le container du libellé (par exemple un <span> ou un <p>), doit avoir un attribut "id" ayant une valeur unique dans la page. L'élément de formulaire aura un attribut "aria-describedby" dont le contenu reprendra celui de l'attribut "id" du container du libellé.
    

Liens évitement

Prévoir des liens de navigation rapides qui seront les premiers éléments présents dans la page et qui permettront : d'aller directement au coeur de page, immédiatement aprés tout élément de de navigation. D'accéder directement à la navigation D'aller directement au moteur de recherche L'idéal est que ces liens soient visibles en permanence, mais, si l'on veut absolument préserver le design, on peut les cacher, et ils devront être apparents dés lors qu'ils recevront le focus au clavier et tant qu'ils le conserveront.
    

Couleurs texte et arriére-plan

Pour chaque spécification de couleur d'arriére-plan il faut que l'on ait une spécification de couleur de texte une faÁon simple de satisfaire à ce critére est de définir des couleurs de texte et d'arriére-plan par défaut sur un élément de haut niveau ( ou ). On a bien une spécification de couleur d'arriére-plan sur le html mais pas de spécification de couleur.
    

Masquage accessible

Dans l'audit, il pourra être fait référence à la notion de masquage accessible. Cette technique consiste à enrichir la page de contenus textuels, qui seront visuellement cachés, mais qui resteront exploitables par les outils d'aide technique tels que les synthéses vocales. Ceci a pour but, lorsque des informations additionnelles sont nécessaires aux utilisateurs de synthése vocale pour la bonne compréhension de la page, de les leur procurer sans modifier l'aspect visuel de la page. Un exemple éprouvé de classe CSS permettant de mettre en place cette fonctionnalité est disponible sous l'url : https://gist.github.com/ffoodd/000b59f431e3e64e4ce1a24d5bb36034 (classe sr-only-) Ce style redéfinit la classe "sr-only", initialement proposée par bootstrap, mais peut être adaptée à n'importe quel contexte de développement. En avoir plus sur le masquage acessible: http://snook.ca/archives/html_and_css/hiding-content-for-accessibility ------------------------------------ Masquage et affichage : la classe "hide" permet de vocaliser un élément tout en le masquant visuellement, il sera lu par la synthése vocale mais ne sera pas affiché à l'écran. Le display :none permet de masquer un élément visuellement et de le masquer également à la synthése vocale : il ne sera pas affiché à l'écran et ne sera pas vocalisé L'attribut aria-hidden="true" permet d'exposer un élément, sans qu'il soit lu par la synthése vocale : il sera affiché à l'écran mais ne sera pas vocalisé.
    

Titles

L'attribut "title" sur un lien est à réserver aux cas dans lesquels le libellé du lien n'est pas assez explicite. Si on l'utilise, il doit reprendre le libellé du lien en le complétant. Dans le cas d'un lien s'appuyant sur une image sans contenu textuel, le title peut être présent mais identique au "alt" de l'image.
      

Mode de calcul

Une premiére notion qu'il faut intégrer, est que l'influence d'un point de contrôle sur le résultat final est binaire : il faut qu'il n'y ait aucune erreur sur un point de contrôle pour qu'il soit considéré comme conforme : qu'il y ait une erreur, ou qu'il y ait 10 erreurs, le résultat sera considéré comme non conforme. Cela fait que si l'on a corrigé 9 des 10 erreurs, le gain en termes de conformité sera nul, alors que le niveau d'accessibilité du site aura été grandement amélioré.
    

Structure

La zone d'en-tête de la page doit être structurée via une balise header.
  Les zones de navigation principales et secondaires doivent être structurées via une balise nav  (réservée à la structuration de ces zones).
  La zone de contenu principal doit être structurée via une balise main unique dans la page.
  La zone de pied de page doit être structurée via une balise footer.
La structure du document doit vérifier ces conditions :
  La zone d'en-tête de la page doit posséder un rôle ARIA banner.
  Le menu de navigation principal doit posséder un rôle ARIA navigation.
  La zone de contenu principal doit posséder un rôle ARIA main.
  La zone de pied de page doit posséder un rôle ARIA contentinfo.
  Le moteur de recherche sur le site doit posséder un rôle ARIA search.
  Les rôles ARIA banner, main, contentinfo et search doivent être uniques dans la page.
  Le rôle ARIA navigation doit être réservé aux zones de navigations principales et secondaires.
      

Date Picker

Le dispositif d'aide à la saisie de date (Date Picker) n'est pas accessible depuis un clavier, mais même en le rendant parfaitement accessible, son usage sera toujours long, fastidieux et décourageant pour une personne aveugle, par rapport à la saisie directe dans un champ bien étiqueté. Aussi il est impératif d'autoriser la saisie directe dans le champ date, et de le lier à une étiquette précisant le format attendu (par exemple "date de naissance (jj/mm/aa)"). Il suffit ensuite de proposer un bouton (avec un libellé significatif : "utiliser l'aide à la saisie de date") situé juste aprés le champ et permettant d'ouvrir le dispositif,  une bonne gestion du focus dans la fenêtre qui héberge le datepicker. L'intérêt est de laisser la possibilité aux personnes voyantes auxquelles un handicap moteur interdit l'usage de la souris de choisir le moyen qui leur est le plus simple entre saisir la date et utiliser le Date Picker.
      

Tooltip

Les boutons ouvrant les tooltip d'info doivent être adressables au clavier, avoir un libellé pertinent, et  avoir un attribut "aria-expanded".
    lorsque l'on a activé le bouton, le focus reste sur le bouton, et si on actionne à nouveau le bouton, cela referme le message.
    Le message doit également se refermer lorsque le focus arrive sur un autre élément interactif (par exemple le champ de saisie suivant) que le bouton d'ouverture du tooltip.
      

Label input

        Le champ de saisie du formulaire (<input>) doit avoir un attribut "id" dont la valeur est unique dans la page, et le libellé doit 'tre présenté dans un élément  dont l'attribut "for" reprendra la valeur de l'attribut "id" du champ de formulaire.
    

Navigation mobile

      Les périphériques Android et IOS intègrent nativement une synthèse vocale, qui peut être activée depuis les paramètres du périphérique.
      Pour parcourir les écrans, l'utilisateur de synthèse vocale aura deux modes principaux d'interaction :
        La navigation séquentielle
        La navigation "au doigt" ou "sous le doigt"
      Le premier mode est la navigation séquentielle, qui consiste  balayer l'écran de droite à gauche. Chaque balayage vocalise les données textuelles de l'élément suivant, dans l'ordre dans lequel les éléments ont été insérés dans la page.
      Le balayage de droite à gauche fait la même chose mais en sens inverse.
      Ce mode de navigation, permet de lister à coup sûr, tous les éléments de la page. Ceci est très pertinent en mode "découverte", pour découvrir de faÁon exhaustive tous les éléments que contient la page. L'inconvénient est que sur une page volumineuse dans laquelle l'élément que recherche l'internaute est situé plutÙt vers la fin de la page, cela peut être long et fastidieux.

      Un deuxième mode que nous appelons "navigation au doigt" ou "sous le doigt", va vocaliser ce qui se trouve sous le doigt à mesure qu'on le déplace sur l'écran. Ce premier mode est intéressant pour une personne non voyante qui connaÓt l'écran dans lequel elle se trouve, et qui sait à peu près ou est positionné l'élément qu'elle cherche. L'inconvénient de ce mode de navigation est que l'on ne vocalisera jamais un élément sur lequel on n'a pas posé le doigt (par exemple un élément ne proposant qu'une surface d'affichage minime à cÙté de laquelle on risque fort de passer) et qu'il est moins efficace  sur une page inconnue de l'utilisateur.
      Il est important de s'assurer que la construction de la page interagit correctement avec ces deux modes de navigation.
    

Validité du code

      Lorsque l'on soumet la page de personnalisation  du compte au validateur html, De nombreuses erreurs html sont signalées.
      Toutefois, toutes les erreurs de validation ne sont pas gênantes pour l'accessibilité.
      Pour mémoire voici les règles à respecter concernant la validité du code :
      les éléments ont des balises de début et de fin complètes,
      ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d'attributs dupliqués
      chaque ID est unique. (Niveau A)
      Note: les balises de début et de fin auxquelles il manque un caractère critique, comme un chevron fermant ou un guillemet pour une valeur d'attribut, sont considérées incomplètes
    

Tabindex

      Les tabindex > 0 : sont à utiliser lorsque l'on veut modifier l'ordre naturel de tabulation dans la page. A utiliser avec beaucoup de précautions car en général si on les emploie il est nécessaire d'en positionner sur tous les éléments focusables de la page. Une page construite de faÁon logique produit un ordre naturel de tabulation qui ne nécessite pas l'usage de tabindex.
      tabindex = 0 : à utiliser pour rendre focusable (au clavier, ou via la fonction JavaScript ".focus()") un élément qui ne l'est pas naturellement, sans modifier l'ordre naturel de tabulation.
      tabindex = -1 : permet de rendre focusable par JS (via la fonction JavaScript ".focus()") sans le rendre focusable au clavier, un élément qui ne l'est pas naturellement.
      Il est préférable d'utiliser un élément naturellement focusable : par exemple, si une li contient un lien, on attachera le focus javascript au lien et non à la "li".
      Les éléments nativement focusables sont les liens et tous les éléments  de formulaire.