que l'accessibilité d'un site Internet ? L'accès facilité pour tous aux informations et au contenu d'un site Pourquoi faire des sites accessibles ? Comment faire des sites accessibles ? Questions/Réponses
évidents • Lutte contre les handicaps (10 à 20% de la population) – Handicap Moteur • Personnes âgées, navigation au clavier, ... – Handicap Visuel • Non voyants • Mal voyants • Daltoniens – Handicap Auditif – Handicap Cognitif • «ne wbies» • étrangers avec une maîtrise partielle de la langue
Section 508 aux EtatsUnis, Disability Discrimination Act en Angleterre et en Australie. • Projet de loi pour « l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées » – L'article 25 prévoit que « les sites et services électroniques des services publics de l'état et des collectivités territoriales et de leurs établissements publics soient accessibles »
aussi (et surtout ?) • Rendre un site accessible consiste à ne pas se focaliser sur l'illusion du contrôle de l'affichage – Meilleure ergonomie et organisation pour tout le monde. – Compatibilité avec tous les navigateurs. – Compatibilité avec toutes les résolutions. – Compatibilité avec d'éventuels réglages personnels. – Compatibilité avec tous les dispositifs matériels. – accommode les connexions lentes
Il est important de ne pas se limiter aux aveugles • On ne peut pas dire d'un site qu'il est “complètement accessible” ou pas – 3 Priorités et 3 niveaux de conformités définis par l'initiative pour l'accessibilité des sites web (WAI) – 3 Labels Accessiweb définis par l'association Braillenet – Il faut adapter ces recommendations aux besoins, aux possibilités et aux priorités.
W3C • Respecter une grammaire (malgré la permissivité des anciens navigateurs) – Fermer les balises, noms des balises en minuscule, valeurs des attributs entre guillemets double, ... – nécessité d'une même grammaire pour tous les navigateurs • Ces standards du web sont proposés par le W3C, ECMA International, ... – choisir un type de document et le spécifier <!DOCTYPE html PUBLIC "//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1strict.dtd"> – l'accessibilité est au coeur des spécifications
• Titres de page uniques et qui ont du sens • Hiérarchie de titres <h.> dans la page • Les liens <a> doivent être compréhensibles hors contexte, utiliser l'attribut title Allez voir mon trésor ≠ Mon trésor est ici • définir acronymes et abbréviations <acronym title=”HyperText Markup Language”>HTML</acronym> • définir citations et références <q lang=”en” hreflang="en" cite=”http://www.joeclark.org/(...)/ AccessManifesto.html”>The true reason to design for accessibility is greed</q> est une citation de <cite>Building Accessible Websites</cite>. « The true reason to design for accessibility is greed » est une citation de Building Accessible Websites.
Appréhender les handicaps cognitifs nécessite une bonne ergonomie. Design simple et clair. • Le contenu multimédia significatif (images en particulier) doit avoir un équivalent textuel. <img href=”logoklee.png” alt=”Klee” /> <img href=”separateur.png” alt=”” /> • Le choix des couleurs est important. • Une information ne doit pas être portée par la couleur. Un lien doit être souligné, ou en gras, ... • Tailles de police relatives peut être un plus. • Feuilles de style alternatives (penser à l'impression). [http://www.csszengarden.com]
la balise link permet de spécifier des aides à la navigation (traductions, documents suivants et précédents, index...) dans l'entête. • le contenu du document doit être accessible très vite. – le placer au début du code et positionner avec CSS. – faire des liens vers les parties importantes (surtout le contenu). • Utiliser accesskey et tabindex. • Formulaire de recherche sur toutes les pages.
(mais pas tout le temps...) • Les ouvertures de nouvelles fenêtres. • Les cadres (<frame>). • Le javascript (6% des utilisateurs sans) – Peut être intéressant, mais ne doit pas être nécessaire à la navigation ou bien il faut des alternatives. – Ne pas compter dessus par exemple pour la validation des entrées d'un formulaire. – Peut limiter l'accessibilité (par exemple, la validation automatique sur liste de choix) <http://www.pikolint.org/~clark/>
tableaux <table summary="exemple de structure d'un tableau de données"> <caption>Tableau de données</caption> <thead> <tr> <th> </th> <th>Titre de droite</th> </tr> </thead> <tfoot> <tr> <th>Titre de gauche</th> <th> </th> </tr> </tfoot> <tbody> <tr> <td>cellule A1</td> <td>cellule B1</td> </tr> <tr> <td>cellule A2</td> <td>cellule B2</td> </tr> </tbody> </table> les tableaux sont à utiliser pour des données tabulaires
• utiliser optgroup et fieldset • utiliser accesskey et tabindex • vérifier que le formulaire est compréhensible en linéaire • éviter le javascript • toujours avoir un bouton de soumission <input type="submit" value="valider"/> • indiquer les champs obligatoires, les erreurs éventuelles – pour des infos complémentaires, utiliser l'attribut title
• Faire une déclaration d'accessibilité visible depuis toutes les pages du site : – Raccourcis clavier – Niveau de respect des standards – Aides à la navigation – Explications sur l'accessibilité • Politique • Références • Logiciels • Services
développement • Se forcer à ne coder que la structure d'abord. La présentation viendra ensuite – Éviter les éditeurs graphique. En tout cas, toujours repasser derrière le code généré. • Valider vos pages. – (X)HTML, CSS, Liens, Accessibilité • Tester dans différents navigateurs. – Lynx pour tester accès séquentiel et affichage limité. – Tester sans les styles (Mozilla Web Developper).