Blog - Britoweb - Accessibilité

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, seules 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.

Référentiel Accessiweb 2.0 : parution officielle

Victor Brito — Thu, 17 Dec 2009 17:10:00 +0100

Le référentiel Accessiweb (celui concernant les sites Web), maintenu par l'association Braillenet évolue dans une nouvelle version, la 2.0, qui vient de paraître officiellement.

Cette nouvelle version est motivée par la publication, l'année dernière, des WCAG 2.0, la nécessité de les faire comprendre et de permettre la vérification de la conformité des sites Web à cette nouvelle version, ainsi que par la parution du RGAA 2.2, qui entraîne un besoin de cohérence avec ce dernier.

Par rapport à la précédente version 1.1, Accessiweb 2.0 maintient la répartition des critères et tests en 13 thématiques, ainsi que les trois niveaux d'accessibilité Bronze, Argent et Or (qui équivalent, respectivement, aux niveaux de conformité A, AA et AAA des WCAG 2.0). De même, on retrouve les deux listes : la liste générale (comprenant les critères, formulés de façon à être compris du plus grand nombre) et la liste déployée (comprenant les tests, dont la formulation emploie un vocabulaire plus technique), ainsi qu'un glossaire expliquant les termes spécifiques employés dans l'intitulé des critères et des tests.

Le principal changement réside dans le nombre de critères et de tests, qui augmente sensiblement : le référentiel Accessiweb 2.0 ne comporte pas moins de 131 critères (81 de niveau Bronze, 20 de niveau Argent et 30 de niveau Or) et de 300 tests (196 de niveau Bronze, 47 de niveau Argent et 57 de niveau Or).

Enfin, le référentiel Accessiweb 2.0 peut être utilisé dans le cadre d'une procédure de certification de conformité d'un site ou d'un service Web aussi bien aux WCAG 2.0 qu'au RGAA 2.2. Autrement dit, le référentiel Accessiweb 2.0 peut être utilisé pour évaluer un service en ligne de l'État, d'une collectivité territoriale ou d'un établissement public qui en dépend (à ceci près qu'un service en ligne évalué qui réussit l'examen d'Accessiweb 2.0 doit être soumis à quelques tests supplémentaires s'il veut être pleinement conforme au RGAA 2.2, les tests étant ceux du RGAA qui divergent d'Accessiweb).

Liens utiles

Le guide Accessiweb sera mis à jour vers la fin du premier semestre 2010.

Ressources sur l'accessibilité du Web et ses apports pour les entreprises

Victor Brito — Tue, 15 Dec 2009 08:50:00 +0100

Le W3C WAI a publié hier plusieurs ressources sur l'accessibilité du Web pour les entreprises, dans un document intitulé Resources for Developing a Web Accessibility Business Case for Your Organization. Ces ressources consistent en des études de cas, des statistiques et des articles qui se concentrent sur le business case pour l'accessibilité du Web.

Plus concrètement, il s'agit de présenter les apports de l'accessibilité du Web pour les entreprises, notamment en termes de trafic, de coûts, de retour sur investissement.

Parmi les ressources déjà disponibles, on peut citer les cas d'étude suivants :

la société Legal & General Group, qui a doublé le nombre de ses visiteurs, réduit ses coûts de maintenance de deux tiers et vu augmenter le trafic issu du référencement naturel de 50 % depuis qu'elle a amélioré l'accessibilité de son site Web ;
la société Tesco, qui a dépensé 35 000 livres sterling pour créer son site Web, accessible, et est parvenu à engranger 13 millions livres sterling de revenus annuels ;
CNET, qui a vu le trafic en provenance de Google croître de 30 % depuis la mise en ligne de transcripts dans une version en HTML de son site Web.

Le document rappelle aussi les risques d'une action en justice ou d'une publicité négative si les entreprises, institutions ou autres organisations ne rendent pas leur site Web accessible, en citant notamment les condamnations de la chaîne de supermarchés américaine Target et du SOCOG, le comité d'organisation des Jeux Olympiques de Sydney de 2000.

Enfin, le W3C WAI recherche d'autres ressources susceptibles de compléter le document, plus particulièrement des études de cas. Si vous faites partie d'une entreprise qui a amélioré l'accessibilité de son site Web ces trois dernières années, sachez que le W3C WAI peut vous aider à recueillir des données et à mener une étude de cas rapportant les impacts de l'amélioration de l'accessibilité. Lisez le billet du blog du W3C intitulé Share Resources Supporting the Web Accessibility Business Case pour en savoir plus.

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.

Un tableau de données lu comme un tableau de mise en forme, et inversement

Victor Brito — Thu, 03 Dec 2009 09:05:00 +0100

En toute logique, un tableau de mise en forme codé en tant que tel est lu comme tel (avec linéarisation et sans aucune indication d'association de cellules) par un lecteur d'écran, qui lira un tableau de données correctement codé (avec les éléments th et les attributs appropriés, scope ou id/headers, pour associer les cellules de données aux cellules d'en-tête correspondantes) en prenant soin d'indiquer le nombre de colonnes et de lignes, ainsi que les associations de cellules explicitées.

Il se trouve que Jaws peut parfois lire un tableau de données comme si c'était un tableau de mise en forme, et inversement.

Dans un billet publié hier sur le blog de WebAIM et initutlé Jaws ate my tables, Jared Smith rapporte que Jaws ne se base pas sur le code source du tableau (notamment en repérant la présence d'éléments th) pour savoir s'il a affaire à un tableau de données ou à un tableau de mise en forme.

Pour que Jaws considère un tableau comme un tableau de données, il faut que ce tableau ait au moins 2 lignes et 2 colonnes et, en même temps, au moins 4 cellules occupant une surface comprise entre 200 et 16 000 pixels au carré. Autrement dit, si un tableau de données comporte une cellule avec beaucoup de texte ou est agrandi par simple agrandissement de la taille de police, Jaws pourra le traiter comme un tableau de mise en forme. À l'inverse, si un tableau de mise en forme comporte au moins 4 cellules, réparties sur au moins 2 lignes et 2 colonnes, qui tiennent dans une surface comprise entre les valeurs indiquées plus haut, il sera lu par Jaws comme si c'était un tableau de données. Pour mieux nous en convaincre, Jared Smith montre deux exemples de tableaux, l'un de données et l'autre de mise en forme, qui ne sont pas lus correctement par Jaws.

En attendant que Freedom Scientific résolve ce dysfonctionnement, Jared Smith invite les utilisateurs de lecteur d'écran à regarder du côté des lecteurs d'écran alternatifs qui, comme NVDA, prennent en charge les tableaux plus convenablement.

Bref, certains seraient tentés, je parie, de penser comme cet utilisateur aveugle commentant le billet de Jared Smith : As a blind user, I find Jaws is like IE6 (En tant qu'utilisateur aveugle, je trouve que Jaws est comme IE 6).

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.

Résultats du deuxième sondage de WebAIM sur les lecteurs d'écran

Victor Brito — Fri, 30 Oct 2009 11:46:00 +0100

Le site WebAIM a organisé un deuxième sondage sur les lecteurs d'écran, qui a recueilli 665 réponses, et dont les résultats sont en ligne et font l'objet d'un résumé sur le blog de WebAIM.

Voici quelques chiffres rapportés par ce deuxième sondage :

les lecteurs d'écran selon leur popularité :
- 75 % des utilisateurs de lecteur d'écran utilisent Jaws,
- 26 % NVDA (qui progresse considérablement depuis le précédent sondage),
- 24 % Window-Eyes,
- 15 % VoiceOver ;
83,6 % des répondants ont mis à jour leur lecteur d'écran favori durant l'année qui s'est écoulée ;
50 % des répondants utilisent un lecteur d'écran sur un téléphone mobile, ce pourcentage s'élevant à 53 % chez les répondants handicapés ;
50,8 % des utilisateurs cherchent de l'information dans une page en consultant d'abord les titres ;
75 % des répondants ont JavaScript activé sur leur navigateur favori ;
42 % des répondants ne savent pas qu'il existe des fonctionnalités de repère fournies par ARIA ;
62,6 % connaissent des difficultés d'accès à des contenus en Flash ;
les médias sociaux les plus utilisés, voire plébiscités, sont YouTube (51,3 %) et les blogs (47,7 %), tandis que LinkedIn (13,4 %) et MySpace (9 %) sont plutôt boudés : d'ailleurs, les répondants reprochent à ces deux derniers d'être inaccessibles, contrairement aux blogs, à YouTube, à Faceook ou à Twitter ;
les difficultés les plus souvent rencontrées en terme d'accessibilité sont les CAPTCHA, l'ambiguïté des liens, la pauvreté ou l'absence d'alternative textuelle, le Flash, les formulaires complexes et le manque d'accessibilité au clavier.

RGAA : l'arrêté enfin paru au Journal Officiel

Victor Brito — Thu, 29 Oct 2009 20:03:00 +0100

Le RGAA a enfin son arrêté, daté du 21 octobre et publié aujourd'hui dans le Journal Officiel.

L'arrêté s'intitule tout simplement Arrêté du 21 octobre 2009 relatif au référentiel général d'accessibilité pour les administrations et ne comporte que deux articles.

Le premier article indique que le RGAA, prévu à l'article premier du décret d'application de l'article 47 de la loi du 11 février 2005, est approuvé et mentionne le site où l'on peut le consulter.

L'article 2 stipule : Le délégué interministériel aux personnes handicapées est chargé de l'exécution du présent arrêté, qui sera publié au Journal officiel de la République française.. Or, il paraît que cette fonction a disparu…

Afin de ne pas me fatiguer à copier-coller, j'invite ceux qui veulent en savoir plus à noter les liens indiqués sur ce billet consacré au RGAA version 2.2.

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.

RGAA version 2.2

Victor Brito — Thu, 01 Oct 2009 12:46:00 +0200

La version 2.2 du RGAA vient d'être publiée.

Toutefois, il ne s'agit pas encore d'une version définitivement validée, comme en atteste le statut du document :

La version en cours prend en compte les recommandations WCAG 2.0 et a fait l'objet d'un appel à commentaires auprès d'un cercle d'experts. Elle est en cours de validation et sera figée suite à la publication de l'arrêté.

En attendant, vous pouvez consulter la version 2.2, qui comporte cinq documents :

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).

Opera 10.10 prendra en charge les descriptions détaillées des images

Victor Brito — Tue, 15 Sep 2009 15:07:00 +0200

Le site 456 Berea Street l'annonce dans un billet intitulé Opera adds support for the longdesc attribute : dans sa prochaine version, la 10.10, Opera prendra en charge l'attribut longdesc.

Pour mémoire, longdesc est un attribut de l'élément HTML img qui permet de fournir une description détaillée de l'image en question quand cette description n'est pas suffisamment concise pour figurer dans l'attribut alt ; sa valeur est l'URL où se trouve la description détaillée en question.

Si l'attribut longdesc est compris des lecteurs d'écran, Jaws en tête, aucun navigateur graphique, en revanche, ne le prenait en charge jusqu'à présent, à l'exception d'iCab. Avec sa prochaine version 10.10, Opera sera le deuxième navigateur graphique à le prendre en charge.

Comment pourra-t-on concrètement, en tant qu'utilisateur « valide », accéder à la longue description ? Henny Swan en rapporte les détails dans un article intitulé Adding longdesc support to Opera 10.10, qu'on peut résumer ainsi :

lorsque le menu contextuel sera ouvert à l'emplacement d'une image comportant un attribut longdesc, on pourra sélectionner Image Description, sélection qui, par défaut, ouvrira un nouvel onglet,
ce même menu contextuel permettra d'accéder à l'URL de la description détaillée, voire de la copier, en consultant les propriétés de l'image.

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.