Blog - Britoweb - Tag - accessibilité

Un manuel didactique pour rendre accessibles les documents PDF

Victor Brito — Wed, 28 Jul 2010 14:37:00 +0200

La société Atalan a mis en place le projet AcceDe sur l'accessibilité des documents PDF. Ce projet était motivé par la quasi absence de documentation, si l'on excepte celle fournie par Adobe, sur l'accessibilité des documents PDF et sur les moyens d'y parvenir.

Ce manque est désormais comblé, puisque le projet AcceDe vient de publier un manuel fournissant l'art de rendre accessible un document PDF avec Adobe Acrobat Pro, ce manuel étant accompagné d'un support d'exercices en deux versions, l'une en PDF balisé, l'autre en PDF non balisé.

Les acteurs de la PAO ne sont pas en reste, puisqu'une notice est également publiée qui leur est destinée et leur fournit les règles d'accessibilité à respecter en phase de conception PAO d'un PDF.

Ces différents documents sont téléchargeables depuis la page manuels du projet AcceDe.

Changement de langue : le contre-exemple du site de l'Élysée

Victor Brito — Thu, 22 Jul 2010 09:10:00 +0200

Non seulement la langue principale d'une page Web doit être déclarée dans le code source afin que les synthèses vocales en restituent correctement le contenu avec la bonne prononciation, mais tout changement de langue au sein de ladite page doit l'être également.

Comme pour la déclaration de la langue principale d'une page Web, chaque changement de langue doit être signalé au moyen de l'attribut lang, qui peut être doublé de l'attribut xml:lang en XHTML, sauf en XHTML 1.1, où seul l'attribut xml:lang est autorisé, comme en XML.

Ceci est également valable lorsqu'il s'agit de contenu multimédia, comme une version audio de la page Web consultée, par exemple.

Or, il se trouve que le site de l'Élysée fournissait une fonctionnalité permettant d'écouter le CV en ligne en anglais du Président de la République. Seulement voilà : faute de signalement dans le code qu'il s'agissait de l'anglais, le CV en ligne était restitué comme s'il avait été rédigé en français, ce qui donnait un résultat pire que l'accent frenchie, résultat qu'on peut encore écouter sur l'article d'Écrans sur la refonte du site de l'Élysée (étant donné que le site de l'Élysée ne permet plus maintenant d'écouter le CV en anglais du Président).

Les techniques WCAG 2.0 appliquées au Flash pointent le bout de leur nez

Victor Brito — Wed, 30 Jun 2010 16:22:00 +0200

Les techniques pour les WCAG 2.0 référencent des techniques permettant de satisfaire aux critères de succès des WCAG 2.0, qui font abstraction des technologies du Web de façon à être applicables au plus grand nombre de technologies du Web, présentes et futures. Parmi ces techniques, on trouve actuellement des techniques générales, des techniques appliquées au HTML et au XHTML, aux CSS, aux scripts côté client et côté serveur, au SMIL, au texte plein et à ARIA, ainsi que des cas d'échec (failures).

Le document listant les techniques pour les WCAG 2.0 est amené à évoluer. C'est pourquoi les techniques pour les WCAG 2.0 appliquées au Flash, permettant de rendre accessibles les animations et autres objets multimédias en Flash, commencent à être publiées.

Attention ! les techniques WCAG 2.0 appliquées au Flash font partie, à l'heure où ces lignes sont rédigées, d'un brouillon de travail rédigé par les auteurs des techniques WCAG 2.0 (Editor's Draft, dans le jargon du W3C).

En tout cas, j'en connais au moins un qui aura matière à lire.

L'accessibilité agile selon Élie Sloïm

Victor Brito — Mon, 28 Jun 2010 18:36:00 +0200

Vous avez certainement entendu parler de développement agile ou de méthode agile, en vous demandant parfois de quoi ces bêtes se nourrissent l'hiver. Voici qu'Élie Sloïm vient de publier sur Openweb (non, ce site n'est pas mort) un article intitulé L'accessibilité agile.

Le concept d'accessibilité agile s'articule sur les points suivants :

un processus et des critères identifiés ;
des recettes rapides sous forme de micro-séances d'expertise ;
des priorisations, autrement dit des priorités à établir dans l'évaluation, car tous les critères d'accessibilité n'ont pas la même importance, la même gravité, la même facilité de vérification ou de résolution ;
des améliorations programmées ;
des itérations rapides, autrement dit la répétition de cycles de recette rapide, de planification et d’amélioration pour vérifier ce qui a été amélioré ;
moins de formalisme, plus d’efficacité ;
un audit complet en fin de chaîne, constat de succès, du moins dans l'idéal.

Pour plus de précisions, je vous invite à consulter l'article.

Comment est vérifiée l'accessibilité des services publics en ligne ?

Victor Brito — Fri, 25 Jun 2010 13:48:00 +0200

Dans un article intitulé Objectif accessibilité des services en ligne pour 2012, paru sur le portail de la DGME, un voile est levé sur la manière dont l'obligation d'accessibilité est prise en compte par les services en ligne de l'État, des collectivités territoriales et des établissement publics qui en dépendent.

L'article en question, en plus de rappeler l'article 47 de la loi du 11 février 2005 et le RGAA, précise que la mise en œuvre du RGAA est assurée par la DGCS et le CIH.

En rappelant que la date butoir de mise en conformité est fixée à 2012, l'article pose la question que tous les acteurs de l'accessibilité numérique se posent : Dans les faits, comment s'assurer que les sites seront effectivement accessibles en temps voulus ? Tout en interrogeant François Tanniou, chargé de mission « Accessibilité dans les nouveaux médias » à la DGCS, l'article apporte les éléments de réponse suivants :

À la précision des préconisations du Référentiel s'ajoute la vigilance quant à leur bonne prise en compte : la DGCS intervient donc à l'occasion de la refonte de chaque site : Dès que j'ai connaissance d'un nouvel appel d'offre, je contacte l'acheteur pour m'assurer qu'il a précisé dans son cahier des charges que le site devra être accessible et savoir comment il entend vérifier que le produit livré est bien conforme à la réglementation, indique François Tanniou. Pour cela, une préconisation reste de rigueur : préciser, dans le cahier des charges, que le prestataire devra pratiquer une partie des tests RGAA.

À la question de savoir si les différents interlocuteurs sont bien partis pour répondre, d'ici 2012, à l'objectif d'accessibilité des services publics en ligne, voici d'autres éléments de réponse :

Les services publics et les acheteurs connaissent cette obligation légale et les prestataires proposent des solutions pertinentes. À tel point que François Tanniou juge possible de créer un palmarès des meilleurs cahiers des charges qui pourraient ensuite être diffusés aux acheteurs comme modèles ou exemples de bonnes pratiques.

En somme, on semble confiant. Reste à voir dans deux ans si cette confiance avait lieu d'être.

L'association Braillenet devient membre du W3C

Victor Brito — Wed, 03 Mar 2010 15:44:00 +0100

C'est officiel : l'association Braillenet est, désormais, membre du W3C, sa candidature ayant été approuvée. Pour le reste, je renvoie au communiqué de presse annonçant l'admission de Braillenet comme membre du W3C.

Souhaitons que Braillenet puisse contribuer de façon décisive à l'accessibilité du Web.

Accessibilité : définir les limites de la démarche

Victor Brito — Fri, 26 Feb 2010 22:34:00 +0100

Accessibilité : où s'arrêter ? Tel est l'intitulé du dernier billet du blog de Temesis, un billet rédigé à quatre mains par Laurent Denis et Élie Sloïm (à moins de l'avoir été avec une seule main chacun, l'autre étant crispée sur la souris), qui discutent de l'accessibilité, plus précisément de la question de savoir où s'arrêter quand on prend en compte l'accessibilité dans un projet Web.

Cette discussion m'inspire les propos suivants.

Ne pas se reposer sur ses lauriers

Il y a de ces projets qui prennent l'accessibilité comme un saint Graal, objet d'un formidable potentiel de communication ou de légitimité, déclare Laurent Denis. Autrement dit, certains acteurs impliqués dans des projets Web et soucieux de l'accessibilité du Web peuvent être tentés de considérer l'accessibilité comme un objectif à atteindre, un objectif relevant d'une sorte d'obsession telle qu'ils n'auront pas de cesse que la pleine accessibilité — ou, du moins, ce qu'ils considèrent comme le stade ultime qui leur fait dire que leur projet est 100 % accessible selon eux — soit atteinte. Et une fois le projet enfin considéré comme accessible, ils se reposent sur leurs lauriers : puisque l'objectif d'accessibilité est atteinte, il n'y a plus rien à faire.

Or, le fait de se reposer sur ses lauriers peut être une attitude à risque : une fois l'objectif d'accessibilité considérée comme atteinte, on n'est jamais à l'abri d'une imprudence au stade de la production ou de la maintenance du projet à l'origine d'une régression en termes d'accessibilité. Si l'obtention du label Accessiweb comporte une visite de contrôle obligatoire du site bénéficiaire un an après son obtention (sans oublier deux autres visites inopinées de même nature pendant la durée de validité du label, ainsi que le canal de plainte), ce n'est pas pour rien : un label de qualité se doit de prévenir toute régression en termes d'accessibilité qui pourrait se produire après l'effort de mise en conformité avec les critères d'Accessiweb (selon le niveau visé) consenti par le propriétaire du site et les prestataires qu'il a sollicités.

Viser l'objectif qui consiste à dire que ses contenus sont accessibles est un non-sens : il est très difficile d'atteindre une accessibilité à 100 % et même les WCAG 2.0 préviennent que ses critères de succès de niveau AAA placent le confort maximal d'accessibilité à une barre trop haute pour que les perchistes de l'accessibilité les plus doués du moment puissent sauter sans la faire tomber, pour ainsi dire. En revanche, on peut s'appuyer sur les moyens de production pour établir une démarche d'accessibilité.

Les moyens de l'accessibilité et leurs limites

Plutôt que viser l'accessibilité comme une fin en soi risquant de compromettre l'efficacité de la communication autour de l'accessibilité, il vaut mieux s'interroger sur les moyens de production à sa disposition pour y parvenir, certes, mais surtout pour établir une démarche d'accessibilité, qui peut être progressive, mais continue. Ces moyens existent et sont documentés aussi bien par les techniques des WCAG 2.0 que par les méthodologies d'évaluation employées par les référentiels qui s'appuient sur les WCAG 2.0.

Ces moyens de production, utilisés à bon escient, permettent l'accessibilité. Toutefois, s'ils peuvent garantir une démarche minimale, voire décente, d'accessibilité, ils ne peuvent garantir un confort d'accessibilité extrême (ou l'accessibilité à 100 % si vous préférez).

Prenons le cas des médias temporels (vidéos, bandes sonores, succession d'images ou de photos en mouvement ou en séquence, par exemple) : les WCAG 2.0 exigent, par exemple, la présence, si nécessaire, de sous-titres synchronisés pour les médias temporels comportant du contenu audio, cette exigence s'appliquant aux contenus audio pré-enregistrés dès le niveau A et aux contenus audio diffusés en direct à partir du niveau AA. Pour une vidéo où l'on entend des personnes ou des voix hors champ parler, il y a moyen d'y ajouter des sous-titres sans difficulté lorsque la vidéo a été préalablement enregistrée et montée en studio : il suffit de noter tout ce qui s'y dit, de formater la transcription des paroles et de synchroniser, le SMIL facilitant la tâche ; en revanche, c'est beaucoup plus difficile lorsqu'il s'agit de sous-titrer un entretien vidéo en direct : cela demande un investissement considérable en moyens financiers et en matériel de pointe tels qu'à l'heure actuelle, seuls les grands groupes de l'audiovisuel peuvent le faire. Voilà donc un exemple de moyen de production dont les limites peuvent compromettre une accessibilité accrue.

Faire du bon Web et viser l'efficacité

Gilles Chagnon, en commentant le billet évoqué, dit, entre autres : Si je devais produire des contenus respectant systématiquement à la lettre tous les normes et critères d'accessibilité, je perdrais grandement en efficacité, au détriment de l'ensemble de mon travail. Cela ne veut pas dire, pour autant, qu'il faille se moquer de l'accessibilité, bien au contraire. L'essentiel est de considérer l'esprit de l'accessibilité, non seulement en tâchant de comprendre les enjeux des points sur lesquels s'attardent les critères de succès des WCAG 2.0, mais aussi en cherchant à contourner les limites des moyens de production, en procédant autrement. Ne peut-on pas, faute de moyens financiers et matériels, sous-titrer une vidéo diffusée en direct ? On ne la diffuse pas en direct et l'on profite de son montage pour la sous-titrer tranquillement, ce qui permet de proposer du contenu efficacement accessible : les utilisateurs sourds ou malentendants y gagneront, ainsi ceux qui n'ont pas de haut-parleurs ou utilisent un ordinateur dont la carte son n'est pas au meilleur de sa forme, sans qu'on ait eu à trop se sacrifier le portefeuille et le matériel pour un résultat moins garanti.

Un autre point où l'accessibilité efficace peut entrer en jeu est la maîtrise de l'environnement technique de l'utilisateur. Le JavaScript, le Flash, voire les CSS, sont des technologies facultatives, en ce sens qu'elles peuvent être désactivées, ignorées ou mal prises en charge, ce qui signifie que le contenu du Web doit être accessible, lisible et compréhensible sans elles, tout en fournissant des alternatives aux fonctionnalités similaires à celles proposées, notamment, par le JavaScript ou le Flash. Dans l'absolu, cette règle est, et demeure, à observer. Mais, si le projet Web sur lequel on intervient cible un environnement technique maîtrisé, on peut y déroger sans pour autant perdre forcément en accessibilité : une application Intranet dont on sait avec certitude qu'elle sera utilisée sur des postes où JavaScript et Flash sont obligatoirement activés et que les utilisateurs de ladite application ne peuvent les désactiver (faute de droits sur leurs machines sur la décision d'un administrateur réseau, par exemple) peut se passer d'alternative au JavaScript et au Flash, d'autant moins qu'on peut produire du JavaScript, et même du Flash, accessible ; et si les utilisateurs de cette application Intranet peuvent tous lire un document PDF, sachez qu'on peut également produire des documents PDF aussi accessibles qu'une simple page Web.

Enfin, penser à l'accessibilité, c'est très bien ; mais, il ne faut pas perdre de vue que l'accessibilité fait partie d'un ensemble de bonnes pratiques qui font un Web de qualité. Cherchez à faire du bon Web, résume Laurent Denis.

Cela dit, pour la qualité Web en général, je préfère laisser la parole à Laurent Denis et, surtout, à Élie Sloïm, qui auraient pu baliser leur dialogue dans leur billet sous forme de liste de définitions.

Ne laissez pas vos pages Web s'intituler « Document sans titre »

Victor Brito — Sat, 20 Feb 2010 17:10:00 +0100

Google retourne environ 25,9 millions de résultats pour la requête « untitled document », 900 000 pour la requête « document sans titre » et 797 000 pour la requête « document sans nom ».

De telles requêtes peuvent être considérées comme concurrentielles (surtout la première mentionnée) ; mais, à part quelques experts en référencement, voire en accessibilité, qui s'amusent à constater l'étendue des dégâts, aucun internaute ne se hasardera à les taper sur leur moteur de recherche favori.

Non seulement une page Web intitulée « document sans titre » aura du mal à se positionner sur les moteurs de recherche (l'élément title revêtant une importance extrême dans le référencement, il convient d'y placer des mots-clés judicieusement choisis pour espérer figurer parmi les premiers résultats ou les deux ou trois premières pages de résultats sur les mots-clés en question), mais elle pose un problème d'accessibilité, en ce sens que le titre de la page Web ne fournit aucun renseignement pertinent sur son contenu.

Le critère de succès 2.4.2 des WCAG 2.0, de niveau A, est formel : Web pages have titles that describe topic or purpose (en français : les pages Web présentent un titre qui décrit leur sujet ou leur but). Autrement dit, une page Web intitulée « document sans titre », si elle n'est d'aucune gêne particulière pour les utilisateurs de navigateur graphique ou de navigateur texte qui peuvent se servir de leurs yeux pour lire directement le contenu de la page, est d'autant plus difficilement compréhensible pour les utilisateurs d'aides techniques (lecteurs d'écran ou loupes d'agrandissement, par exemple) que ces derniers sont obligés de parcourir l'ensemble de la page Web pour savoir de quoi elle parle, ce qui peut leur faire perdre du temps (rappelons qu'un internaute, qu'il soit ou non handicapé, est généralement pressé) s'ils se rendent compte que la page n'est pas celle qu'ils voulaient consulter ou ne les intéresse pas.

Bref, pensez à bien intituler vos pages Web, d'autant que l'élément title est le premier restitué par les lecteurs d'écran lorsqu'ils chargent une page au moyen d'une URL sans ancre. Ce conseil s'adresse surtout à ceux qui utilisent des logiciels WYSIWYG qui tendent fâcheusement à remplir certains éléments HTML d'une valeur par défaut (les CMS, pour leur part, étant généralement bien conçus pour intituler correctement les pages Web qu'elles gèrent et génèrent).

Pour finir, je remercie Élie Sloïm, de Temesis, d'avoir posté il y a deux jours un tweet qui m'a inspiré ce billet.

Information véhiculée et couleur : un contre-exemple du site Travailler mieux

Victor Brito — Sat, 20 Feb 2010 16:14:00 +0100

Le site Web Travailler mieux, un site dépendant du Ministère du Travail, a mis en ligne récemment trois listes d'entreprises, selon que ces dernières ont mis en place ou non un plan d'action ou un accord sur la prévention du stress au travail et des risques psychosociaux.

Ce billet ne reviendra pas sur la polémique suscitée par la manière dont certaines entreprises ont été classées (parfois automatiquement). Il ne s'agit, ici, que de parler du point suivant : sur la page du Plan d'urgence sur la prévention des risques psychosociaux, on remarque la présence d'une liste de trois liens pointant vers chacune des trois listes de classement des entreprises. Cette liste est codée comme suit :

<ul>
<li><a href="http://www.travailler-mieux.gouv.fr/spip.php?page=stress_liste&amp;cla=1" class="green">Entreprises listées en VERT</a></li>
<li><a href="http://www.travailler-mieux.gouv.fr/spip.php?page=stress_liste&amp;cla=2" class="orange">Entreprises listées en ORANGE</a></li>
<li><a href="http://www.travailler-mieux.gouv.fr/spip.php?page=stress_liste&amp;cla=3" class="red">Entreprises listées en ROUGE</a></li>
</ul>

Chaque lien a son arrière-plan colorié, respectivement, en vert, orange et rouge. Il en est de même pour les listes d'entreprises correspondantes.

Une information, pour qu'elle soit accessible, ne doit pas être véhiculée uniquement par la couleur, comme le rappelle le critère de succès 1.4.1 des WCAG 2.0, de niveau A : Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element (en français : La couleur n'est pas utilisée comme la seule façon de véhiculer de l'information, d'indiquer une action, de solliciter une réponse ou de distinguer un élément visuel).

Dans le cas examiné, lorsque les couleurs ne sont pas correctement restituées, soit parce que le support informatique utilisé pour consulter la page restitue mal les couleurs (utilisation de niveaux de gris ou nombre restreint de couleurs prises en charge) soit parce que l'utilisateur est daltonien, l'information véhiculée devient plus difficile à comprendre, comme le montrent ces trois captures d'écran des liens, qui montrent, respectivement, leur affichage avec des niveaux de gris, leur affichage chez un daltonien atteint de protanopie et chez un daltonien atteint de deutéranopie.

À cela il faut ajouter que les couleurs sont entièrement perdues pour les utilisateurs de lecteur d'écran.

Enfin, la page n'explique pas à quoi correspondent les entreprises listées respectivement en vert, orange et rouge.

Pour rendre cette information plus compréhensible, et donc plus accessible, il suffit d'expliciter à quoi correspondent ces différentes listes, notamment en retravaillant l'intitulé des liens, de façon à ce qu'il indique clairement ce qu'on trouvera dans la page vers laquelle ils pointent. En effet, les utilisateurs de lecteurs d'écran ont la faculté d'ouvrir une boîte de dialogue listant tous les liens de la page, qui sont donc isolés de leur contexte (même si la dernière version de Jaws permet de fournir le contexte de ces liens, en indiquant le contenu du paragraphe où ils se trouvent ou le titre de section le plus proche) ; or, les trois liens en question, tels qu'ils sont intitulés, ne sont pas suffisamment explicites, même dans leur contexte. Pour qu'ils soient plus explicites, ils doivent être intitulés, par exemple, comme suit :

<ul>
<li><a href="http://www.travailler-mieux.gouv.fr/spip.php?page=stress_liste&amp;cla=1" class="good">Liste des entreprises ayant un plan de prévention et d'action</a></li>
<li><a href="http://www.travailler-mieux.gouv.fr/spip.php?page=stress_liste&amp;cla=2" class="warning">Liste des entreprises prévoyant un plan de prévention et d'action</a></li>
<li><a href="http://www.travailler-mieux.gouv.fr/spip.php?page=stress_liste&amp;cla=3" class="bad">Liste des entreprises n'ayant aucun plan de prévention et d'action</a></li>
</ul>

Bien entendu, l'usage de la couleur n'est pas interdit : l'essentiel est que la couleur apporte un confort d'utilisation supplémentaire pour les utilisateurs ayant une bonne perception des couleurs (une amélioration progressive, en quelque sorte). Soit dit en passant, dans le code ci-dessus, le nom des classes a été modifié afin de se conformer à cette bonne pratique, qui consiste à nommer les classes selon la sémantique, et non selon la mise en forme : il suffit d'imaginer qu'on décide de remplacer le rouge par du noir, ou l'orange par une nuance de jaune, pour mieux s'en convaincre…

Accessibilité améliorée pour Target.com

Victor Brito — Fri, 12 Feb 2010 10:57:00 +0100

Le site Web de Target, une chaîne de supermarchés américaine, a défrayé la chronique à cause de la condamnation de son propriétaire pour inaccessibilité, à l'issue d'une action en justice intentée par la NFB (j'en ai parlé dans un autre billet). Depuis cette condamnation, des efforts ont été menés.

Le blog de WebAIM, dans un billet intitulé Target.com Accessibility, rapporte que le site Target.com est désormais suffisamment accessible. Même la NFB a daigné certifier l'égale accessibilité du site aussi bien aux utilisateurs voyants qu'aux utilisateurs aveugles.

Cette satisfaction est résumée ainsi : Sporting a new design and accessibility features, the site can be considered a wonderful model of an accessible corporate e-commerce site (en français : Arborant un nouveau design et des fonctionnalités d'accessibilité, le site peut être considéré comme un merveilleux modèle de site de commerce électronique accessible appartenant à une société). Parmi les fonctionnalités améliorant l'accessibilité, on remarquera notamment la manière dont les liens d'évitement sont implémentés : invisibles pour les utilisateurs d'une souris, ils n'apparaissent que lorsqu'ils reçoivent le focus quand on navigue au clavier, outre que l'utilisation du positionnement absolu les rend parfaitement atteignables par les lecteurs d'écran.

Tutoriel sur l'accessibilité du Flash

Victor Brito — Mon, 25 Jan 2010 15:56:00 +0100

Certains pouvaient croire que le site Access-Key était mort, pour ainsi dire. Il n'en est rien, puisqu'un nouveau tutoriel vidéo sur l'accessibilité du Flash et des composants externes vient d'être mis en ligne (la vidéo nécessite le plug-in Flash, d'ailleurs, que vous pouvez télécharger sur le site d'Adobe).

Même si une version textuelle constitue une bonne alternative au contenu en Flash, il est dommage que le tutoriel vidéo n'aborde pas l'accessibilité du Flash : en effet, on peut rendre un objet en Flash accessible, notamment aux utilisateurs de lecteur d'écran et aux utilisateurs qui naviguent exclusivement au clavier (la page d'accueil du site de Groupama en montre un exemple).

Quatrième Forum Européen de l'Accessibilité Numérique : le programme

Victor Brito — Fri, 15 Jan 2010 17:34:00 +0100

Le quatrième Forum Européen de l'Accessibilité Numérique se tiendra le 12 avril prochain à Paris, à la Cité des Sciences et de l'Industrie.

Le programme de ce prochain forum est disponible depuis aujourd'hui et s'articule sur quatre thématiques :

les politiques d'accessibilité numérique,
les outils pour encourager l'accessibilité numérique,
une chaîne d'édition numérique accessible,
les aspects sociétaux.

Ce sera, entre autres, l'occasion de découvrir le ReNo, le référentiel de qualité Web du gouvernement luxembourgeois, et d'avoir un retour d'expérience sur la mise en œuvre de l'accessibilité numérique à la Direction de l'Information Légale et Administrative (issue de la fusion du Journal Officiel et de la Documentation Française).

La présentation complète, le programme complet, les inscriptions et les tarifs sont disponibles sur la page dédiée au quatrième Forum Européen de l'Accessibilité Numérique.

Nouvel outil de vérification du contraste des couleurs selon les WCAG 2.0

Victor Brito — Sat, 12 Dec 2009 21:09:00 +0100

Cela fait un an que les WCAG 2.0 ont acquis le statut de recommandation (qui fut ensuite traduite en français). Bon nombre d'évolutions et de changements se présentent par rapport aux WCAG 1.0, dont l'algorithme utilisé pour évaluer le contraste des couleurs.

Le nouvel algorithme utilisé ne se base plus sur les notions de différence de couleur et de différence de luminosité, mais sur la notion de ratio de contraste, lui-même basé sur la luminosité relative des couleurs.

Afin de faciliter l'évaluation du contraste des couleurs dans l'esprit des WCAG 2.0, un nouvel outil de vérification de contraste des couleurs est désormais disponible (celui basé sur l'algorithme préconisé dans les WCAG 1.0 restera toujours en ligne).

Le principe reste le même : vous saisissez le code hexadécimal à six chiffres (sans le dièse initial) respectif de la couleur de premier-plan et de celle d'arrière-plan que vous souhaitez utiliser dans vos feuilles de style ou dans vos maquettes graphiques. Une fois le formulaire soumis, le verdict tombe, qui indique si le contraste est suffisant selon le contexte : texte agrandi ou pas, texte en gras ou pas, contraste minimum (niveau AA des WCAG 2.0) ou amélioré (niveau AAA des WCAG 2.0).

Les notations raccourcies du code hexadécimal, lorsqu'elles existent (par exemple, #369 pour #336699), sont autorisées. En revanche, les mots-clés de couleur utilisés en CSS ne peuvent être utilisés, ni le code décimal (par exemple : 128, 128, 255). Pour rappel, les mots-clés de couleur en CSS correspondent aux codes hexadécimaux suivants :

maroon : #800000,
red : #ff0000 (ou #f00),
orange : #ffa500,
yellow : #ffff00 (ou #ff0),
olive : #808000,
purple : #800080,
fuchsia : #ff00ff (ou #f0f),
white : #ffffff (ou #fff),
lime : #00ff00 (ou #0f0),
green : #008000,
navy : #000080,
blue : #0000ff (ou #00f),
aqua : #00ffff (ou #0ff),
teal : #008080,
black : #000000 (ou #000),
silver : #c0c0c0,
gray : #808080.

Référentiel Accessiweb 2.0 : appel à commentaires

Victor Brito — Mon, 09 Nov 2009 17:50:00 +0100

L'association Braillenet planche actuellement sur une nouvelle version de son principal référentiel : la version 2.0, dont les objectifs sont de permettre une compréhension opérationnelle des WCAG 2.0, permettre de vérifier la conformité aux WCAG 2.0 et être cohérent avec RGAA 2.2, outre le fait de fournir une méthode pour la certification de conformité.

Dans ce cadre, elle vient de lancer un appel à commentaires publics. N'importe qui peut consulter le texte actuel du référentiel et soumettre des remarques à ce sujet, et ce jusqu'au 26 novembre prochain.

Vous trouverez plus de renseignements sur la page de l'appel à commentaires publics sur le site de Braillenet.

Un site sur le design et le daltonisme

Victor Brito — Tue, 27 Oct 2009 16:44:00 +0100

Outre les problèmes liés au contraste, l'emploi de la couleur peut causer des problèmes d'accessibilité pour les utilisateurs daltoniens.

Étant donné que la prise en compte du daltonisme commence dès le stade de l'élaboration des maquettes graphiques (et même de la charte graphique), un site Web a vu le jour, qui est susceptible d'intéresser les graphistes et autres webdesigners : We are Color Blind, qui fourmille d'exemples (bons et mauvais) de modèles de design.

À ajouter à vos signets.

Parution du Référentiel Accessiweb CMS 1.0

Victor Brito — Mon, 12 Oct 2009 21:05:00 +0200

Aujourd'hui, l'association Braillenet a publié la version 1.0 d'un nouveau référentiel en matière d'accessibilité du Web : le référentiel Accessiweb CMS.

Le but de ce référentiel est d'évaluer la capacité des CMS à produire du contenu accessible. Il s'agit, comme tout référentiel Accessiweb qui se respecte, d'une méthode d'application d'un standard du W3C, en l'occurrence des ATAG 1.0, un ensemble de règles d'accessibilité pour les outils d'édition de contenu (pour information, une version 2.0 est en cours d'élaboration).

En résumé, le référentiel Accessiweb CMS 1.0 distingue, à l'instar du référentiel Accessiweb tout court, trois niveaux : Bronze, Argent et Or ; il comporte 75 critères (43 de niveau Bronze, 22 de niveau Argent et 10 de niveau Or) et 136 tests (93 de niveau Bronze, 29 de niveau Argent et 14 de niveau Or), répartis en 15 thématiques (celles du référentiel Accessiweb, plus les thématiques « Autres fonctionnalités » et « Général »).

Voici des liens menant directement vers les ressources concernées :

Il ne reste plus qu'à mettre en place une galerie des CMS générateurs de sites Web accessibles.

Formation à l'accessibilité, avec diplôme, à l'Université Pierre et Marie Curie

Victor Brito — Sun, 27 Sep 2009 16:22:00 +0200

L'accessibilité du Web est un besoin de plus en plus prépondérant, voire une obligation pour les services publics (surtout depuis la parution du décret d'application de l'article 47 de la loi du 11 février 2005). Or, mettre des sites Web aux normes de l'accessibilité exige des compétences et des connaissances qui ne s'improvisent pas, surtout quand il s'agit de cerner les difficultés qu'induit un handicap lors de la consultation d'un site Web. C'est pourquoi il existe des offres de formation, qui s'étoffent.

Il existe déjà des formations à l'accessibilité dispensées par la société Temesis (axée sur le RGAA) et par l'association Braillenet (qui forme les experts Accessiweb en évaluation), pour ne citer que ces deux organismes. On peut y ajouter une autre formation, intitulée Accessibilité du Web : obligations, normes et application et dispensée par l'Université Pierre et Marie Curie, à Paris, en partenariat avec l'association Braillenet.

Cette formation dure 106 heures, sur 9 semaines, et débouche sur l'obtention d'un Diplôme d'Université de niveau Bac +3. Ses objectifs sont les suivants :

Pour le secteur public, respecter l'obligation légale de l'accessibilité du Web aux personnes handicapées.

Pour le secteur privé, participer à la construction d'une société numérique équitable.

Objectifs opérationnels :

Organiser une veille stratégique, législative et technologique sur les questions d'accessibilité du Web.

Évaluer l'accessibilité d'un site et service Internet et Intranet.

Conseiller pour sa mise en conformité.

Comprendre les normes d'accessibilité (WCAG 2.0 notamment).

La formation comporte des cours (avec, notamment, des démonstrations par des personnes handicapées), des travaux pratiques, des exercices et des projets réalisés en groupe, sans oublier un examen final.

La première session aura lieu du 16 au 19 novembre, les 14 et 15 décembre 2009 et les 11 et 12 janvier 2010 ; la seconde session du 8 au 11 février, les 15 et 16 mars et les 3 et 4 mai 2010.

Pour en savoir plus, vous pouvez consulter la présentation du Diplôme d'Université Accessibilité du Web : obligations, normes et application, par l'Université Pierre et Marie Curie (PDF, 107,26 ko).

Accessibilité et esprit d'entreprise : le contre-exemple du site de la SBA

Victor Brito — Fri, 21 Aug 2009 23:51:00 +0200

Ce n'est pas parce qu'on est en situation de handicap qu'on s'interdit d'avoir l'esprit d'entreprise, de produire des richesses ou des services et de tenter de prospérer en démarchant de nouveaux clients et emportant des appels d'offres.

Le Web est un moyen de mise en contact entre les entrepreneurs et les marchés qu'ils ciblent. Et plus le Web est accessible, plus les entrepreneurs touchés par un handicap qui les contraint à utiliser le Web autrement peuvent être équitablement en compétition avec leurs concurrents valides.

Récemment, aux États-Unis, la NFB et Virgil Stinnett, un patron non-voyant d'Honolulu proposant des services autour de repas fournis aux militaires, ont déposé une plainte administrative contre la SBA, une agence fédérale américaine d'aide aux entreprises.

Ils reprochent au site Web de la SBA d'être inaccessible aux aveugles et mal-voyants, en violation de la Section 508. Le manque d'accessibilité du site Web en question se traduit par l'impossibilité pour les utilisateurs aveugles de remplir les formulaires ou de consulter les cours en ligne proposés par la SBA. Dans le cas concret de Virgil Stinnett, l'inaccessibilité du site l'a empêché de postuler à une certification dont l'obtention donnerait un sérieux coup de pouce à ses affaires, en lui permettant d'accéder aux appels d'offres venant aussi bien des institutions fédérales que du secteur privé.

Les concepteurs du site Web de la SBA auraient-ils oublié que l'esprit d'entreprise pouvait aussi toucher des aveugles et que, par conséquent, il fallait s'assurer d'un minimum d'équité quand l'enjeu est la compétitivité des entreprises ? C'est le message que donne à entendre le président de la NFB, Marc Maurer :

Blind Americans have the same dreams, the same goals, and the same entrepreneurial spirit as all other Americans. If we are to have equal access to the tools and techniques needed to be effective business owners and to compete on terms of equality with our sighted peers, we must have equal access to the resources offered on the SBA Web site and other government sites. The National Federation of the Blind demands equality for blind business owners and will tolerate nothing less.

En français :

Les aveugles américains ont les mêmes rêves, les mêmes buts et le même esprit d'entreprise que tous les autres Américains. Si nous devons avoir l'égalité d'accès aux outils et techniques nécessaires pour être des patrons efficaces et être en compétition à égalité avec nos confrères voyants, il nous faut l'égalité d'accès aux ressources offertes sur le site Web de la SBA et sur d'autres sites gouvernementaux. La National Federation of the Blind exige l'égalité pour les patrons aveugles et ne tolérera rien de moins.

Autrement dit, le manque d'accessibilité d'un site Web fournissant de l'aide aux entreprises est nuisible à l'esprit d'entreprise, générant perte de temps et frustration, comme le souligne Virgil Stinnett :

As a blind entrepreneur, access to the SBA Web site is critical in order for me to use its programs and services and expand my business. The fact that I could not access the Web site has cost me time and resources that I would not have needed to expend if I had been able to use the site like everyone else. I hope the action we are taking today will prompt the SBA to take immediate steps so that all Americans, blind and sighted, have equal access to the programs, training, and resources that it provides.

En français :

En tant qu'entrepreneur aveugle, l'accès au site Web de la SBA est crucial afin que j'utilise ses programmes et services et déploie mes affaires. Le fait que je ne pouvais pas accéder au site Web m'a coûté du temps et des ressources dont je me serais passé si j'avais été capable d'utiliser le site comme tous les autres. J'espère que l'action que nous menons aujourd'hui incitera la SBA à prendre des mesures immédiates, de façon à ce que tous les Américains, aveugles comme voyants, aient une égalité d'accès aux programmes, formations et ressources qu'elle fournit.

Pour en savoir plus à ce sujet, vous pouvez, si l'anglais ne vous fait pas peur, consulter le communiqué de la National Federation of the Blind, intitulé National Federation of the Blind and Blind Business Owner File Complaint with Small Business Administration.

Pour conclure, je souhaite que notre entrepreneur aveugle voie sa petite entreprise ne pas connaître la crise.

Démonstration de l'utilisation d'un lecteur Braille

Victor Brito — Thu, 11 Jun 2009 22:10:00 +0200

Si jamais vous avez toujours voulu savoir comment un internaute aveugle utilise un lecteur Braille pour surfer sur le Web, vous voici comblé. En effet, Roger Hudson a rencontré Bruce Maguire, un aveugle australien, qui explique comment il utilise son lecteur Braille pour consulter les sites Web (il le préfère à l'utilisation de lecteur d'écran en mode synthèse vocale), sans oublier d'évoquer son expérience d'utilisateur.

Le tout est rassemblé dans une vidéo (couplée à un transcript) publiée dans le billet Refreshable Braille and the Web, sur le site DingoAccess.

Pour ceux qui ne le connaissent pas, Bruce Maguire est connu pour avoir, en 2000, intenté un procès pour inaccessibilité d'un site Web (le premier procès connu de ce genre) contre le Comité d'Organisation des Jeux Olympiques de Sydney, qui fut condamné à le dédommager à hauteur de 20 000 dollars australiens (cette affaire est évoquée, parmi d'autres, dans un billet publié en août dernier et intitulé Si votre site n'est pas accessible, la justice pourra vous le rappeler).

Configuration de la navigation au clavier dans les navigateurs sous Mac OS X

Victor Brito — Wed, 10 Jun 2009 00:29:00 +0200

Par défaut, les navigateurs disponibles sous Mac OS X ne sont pas configurés de façon à fournir d'emblée la possibilité de naviguer au clavier. Dieu merci, ce n'est que par défaut.

Pour les utilisateurs de Mac OS X qui ne souhaitent ou ne peuvent utiliser la souris et pour tous ceux qui veulent évaluer sous Mac OS X l'accessibilité d'un site Web dans le domaine de la navigation au clavier, 456 Berea Street a publié un billet indiquant comment configurer la navigation au clavier dans Firefox, Opera, Safari, Camino et Omniweb. Même si le mode d'emploi est en anglais, il n'est pas difficile à suivre.