Blog - Britoweb - Tag - accessibilité web

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.

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.

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.

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.

Spip 2 d'Anne-Laure et Dominique Quatravaux : note de lecture

Victor Brito — Tue, 21 Apr 2009 18:03:00 +0200

Les éditions Eyrolles ont publié ce mois-ci Spip 2 - Premiers pas pour créer son site Web, d'Anne-Laure et Dominique Quatravaux (avec la contribution de Sandrine Burriel).

Ce livre est fidèle à la démarche pédagogique de son prédécesseur, Spip 1.9. En plus de promouvoir la version 2 du CMS Spip, d'exposer les différences avec les versions antérieures et de donner des conseils pour migrer vers Spip 2.0, il garde une clarté de propos ravissant le grand public et n'oublie pas de promouvoir d'autres logiciels libres, notamment OpenOffice, tout en continuant de prêcher pour l'accessibilité du Web.

Une remarque toutefois : au chapitre exposant le HTML et les CSS, une erreur s'est glissée : l'élément HTML servant mettre en exergue du texte n'est pas emph, mais em.

Pas d'accessibilité nuit à l'attirance de clients potentiels : l'exemple du service de vidéo à la demande de TF1

Victor Brito — Tue, 27 Jan 2009 22:16:00 +0100

Un des rédacteurs de Framablog a publié aujourd'hui un billet où il rapporte son amère expérience du service de vidéo à la demande de TF1, billet intitulé VoD : l'interopérabilité selon TF1.

En voulant télécharger deux épisodes d'une série télévisée américaine dont il est fan, il est tombé sur les écueils suivants :

le service de vidéo à la demande de TF1 n'est accessible que sous Windows XP,
il n'est accessible que sous Internet Explorer (version 6 minimum),
les vidéos proposées ne sont accessibles que sous Windows Media Player (version 10 minimum),
les cookies doivent être acceptés.

Ainsi, le service de vidéo à la demande de TF1 :

se coupe des utilisateurs d'autres systèmes d'exploitation (Mac OS X, Linux), ainsi que des utilisateurs des autres versions de Windows (il est même surprenant que Windows Vista soit exclu, et je n'ose parler des courageux qui essaient la bêta de Windows 7…),
se coupe des utilisateurs de Windows XP qui utilisent un navigateur autre qu'Internet Explorer (a-t-on pensé, chez TF1, que Firefox jouit, actuellement, de parts de marché dont le pourcentage s'exprime à deux chiffres avant la virgule ?),
se coupe des utilisateurs d'Internet Explorer qui utilisent un lecteur multimédia autre que celui de Microsoft ou une ancienne version de Windows Media Player (il existe des utilisateurs de Windows qui ne mettent pas à jour les logiciels installés sur leur PC),
se coupe des utilisateurs de Windows Media Player qui sont à jour du logiciel, mais désactivent systématiquement les cookies pour diverses raisons.

On imagine donc très bien des cercles concentriques de l'enfer de l'inaccessibilité.

Non seulement le service de vidéo à la demande de TF1 manque d'accessibilité parce qu'il n'offre pas à ses utilisateurs potentiels le choix des programmes à utiliser (le rédacteur de Framablog parle même, à juste titre, de mépris de l'interopérabilité), mais ce manque d'accessibilité induit surtout un risque d'ordre commercial pour TF1 : si jamais un concurrent propose un service de vidéo à la demande qui fonctionne sur plusieurs plateformes (Windows, Mac OS X, Linux…), indépendamment du navigateur utilisé, voire propose des vidéos dans plusieurs formats différents (WMV, MPEG, Quicktime, peut-être Ogg…), et que les utilisateurs mis à l'écart par les écueils cités plus haut l'apprennent et y courent, cela fera autant de clients en moins et du chiffre d'affaires en moins pour TF1. Et je ne me hasarde pas à parler de la tentation, chez certains de ces utilisateurs frustrés, de recourir à des moyens illégaux pour satisfaire leur demande…

Autrement dit, pour reprendre un commentaire du rédacteur de Framablog : il est tout de même étonnant que commercialement, comme je l'écris dans le billet, ils n'aillent que vers le plus évident et se coupent ainsi d'un bon nombre de clients potentiels, sachant que les utilisateurs de Mac et de Linux, souvent assez férus de technologie, seraient sans doute très susceptibles d'être intéressés par cette offre de VoD.

C'est une preuve, s'il en est, qu'appliquée à un site commercial (ou à un service commercial proposé par un site dont l'activité ne se réduit pas à des considérations marchandes), l'accessibilité ne nuit pas aux affaires : bien au contraire, tout en véhiculant une image respectable du site, elle aide ce dernier à attirer plus de clients potentiels et à augmenter ses chances de faire croître son chiffre d'affaires.

Bonne année 2009

Victor Brito — Thu, 01 Jan 2009 15:23:00 +0100

Que cette année 2009 soit une année de progrès en matière de respect des standards du Web (de préférence avec une baisse accrue des parts de marché d'Internet Explorer 6 et un très bon accueil de Firefox 3.1, d'Opera 10, de Safari 4 et, dans une moindre mesure , d'Internet Explorer 8) et d'accessibilité des sites Web (avec ou sans décret ).

Une astuce pour l'accessibilité des champs de formulaire obligatoires

Victor Brito — Tue, 16 Dec 2008 12:06:00 +0100

Fabrice Bonny expose, dans un billet du blog de Temesis, ce qu'il pense être une nouvelle technique pour améliorer l'accessibilité des champs de formulaire, plus particulièrement les champs obligatoires.

Plutôt que d'une nouvelle technique, il s'agit d'une astuce qui part du constat suivant : souvent, la mention des champs obligatoires est effectuée au moyen d'une astérisque (*), qui est très souvent refoulée après le champ concerné, au lieu de se trouver à côté du libellé (ou étiquette) du champ.

Faut-il donc rapprocher systématiquement l'astérisque de l'intitulé ? Pas nécessairement. En effet, l'élément HTML label peut être parent de l'élément HTML employé pour le champ de formulaire (que ce soit input, select ou textarea) : c'est ce qu'on appelle l'association implicite du libellé du champ et du champ correspondant. Dans ce cas, on pourra toujours placer l'astérisque après le champ, mais à l'intérieur de l'élément label ; de plus, pour que l'association du libellé et de son champ soit bien repérée, on ajoutera l'attribut for à label, qui reprend la valeur de l'attribut id du champ en question. Ce qui donne le code suivant :

<form action="">
  <p>Les champs accompagnés d'une astérique (*) sont obligatoires.</p>
  <p>
    <label for="obligatoire">
      Libellé du champ
      <input id="obligatoire" name="obligatoire" type="text" />
      *
    </label>
  </p>
</form>

Les aides techniques, telles que les lecteurs d'écran, tiendront compte de l'astérisque comme partie intégrante du libellé du champ : Jaws, par exemple, lira bien les deux parties du contenu textuel de l'élément label.

Fabrice Bonny fournit un exemple de formulaire accessible selon cette méthode, dont le code source est enrichi par rapport au code ci-dessus : des éléments HTML sont ajoutés, comme span autour de la première partie de chaque libellé et strong autour de chaque astérique, de quoi permettre d'appliquer au formulaire un design élaboré.

Dans la peau de Willy, un webmaster peu soucieux d'accessibilité

Victor Brito — Mon, 24 Nov 2008 18:08:00 +0100

Il était une fois Willy, un webmaster qui venait de réaliser un nouveau site Web. Un jour, il reçut un courriel envoyé par Julia, dont l'objet était intitulé Votre tout nouveau site Web :

Cher webmaster,
Étant malvoyante, je n'ai pas accès aux infos sur votre site web.

Julia

Que doit faire Willy ?

Envoyer un courrier en braille ?
Ne rien faire (de toute façon, les personnes malvoyantes n’ont pas accès à Internet) ?
Respecter les règles d’accessibilité du Web ?

Une seule réponse est correcte. Saurez-vous laquelle ?

Si vous répondez : Envoyer un courrier en braille

C'est sympa de votre part, mais cela ne résoudra pas le problème pour les autres internautes malvoyants…

Si vous répondez : Ne rien faire

Honte à vous ! Les personnes porteuses d'un handicap utilisent régulièrement Internet grâce à des aides techniques.

Si vous répondez : Respecter les règles d'accessibilité du Web

Que vous connaissiez le problème ou que vous ayez répondu par intuition ou par pur hasard, bravo ! Félicitations, vous êtes sur la bonne voie ! Rendre un site accessible à tous comporte d'ailleurs de nombreux avantages.

L'intérêt de ce billet ?

Tout ça pour dire qu'Altéo, un mouvement social de personnes malades, valides et handicapées, vient de lancer une campagne en ligne de sensibilisation à l'accessibilité du Web.

Le site Willy on the Web, en plus de ce quizz original, fournit des liens vers des pages du site d'Altéo expliquant ce qu'est l'accessiblité et quels sont ses avantages, prodiguant des conseils pour rendre un site Web accessible et rapportant, en plus d'une revue de presse, des témoignages d'internautes handicapés. Bref, un site à classer, avec Access-Key, au nombre des sites percutants d'efficacité.

Passer des WCAG 1.0 aux WCAG 2.0 en douceur

Victor Brito — Thu, 06 Nov 2008 19:13:00 +0100

Depuis 3 jours, la spécification de la version 2.0 des WCAG, un ensemble de directives pour l'accessibilité du Web élaborées par le W3C, a le statut de proposition à la recommandation (proposed recommendation en anglais), ce qui, dans le jargon du W3C, signifie qu'on a affaire à un document dont l'élaboration est au stade ultime avant la consécration octroyée par le terme de recommandation du W3C.

Qui dit nouvelle version d'une spécification du W3C dit adaptation éventuelle des documents et autres applications concernées par la spécification pour qu'ils soient conformes à la nouvelle version. Dans cette perspective, afin que la transition des WCAG version 1.0 aux WCAG 2.0 soit le moins rude possible, le Web Standards Project vient de publier un billet suggérant des ressources sur les WCAG 2.0. La liste ébauchée ne contient que des documents en anglais ; mais, elle a, néanmoins, le mérite d'exister. D'ailleurs, ce billet invite également à mentionner, dans les commentaires, d'autres ressources autour des WCAG 2.0.

Google Labs expérimente un affichage des résultats plus accessible

Victor Brito — Fri, 31 Oct 2008 14:25:00 +0100

Olivier Andrieu rapporte dans un article paru aujourd'hui sur Abondance que Google Labs essaie de rendre les résultats de recherche affichés par le moteur de recherche plus accessibles.

Cette expérimentation en cours s'appelle Experimental search. Elle permet la navigation au clavier, ainsi que la possibilité d'utiliser des raccourcis clavier, qui sont documentés, outre que chaque résultat de recherche peut être agrandi.

Toutefois, il faut mettre un bémol à cette initiative : en effet, l'outil n'est disponible que pour Firefox 3 et la fonction d'agrandissement que pour Safari et Chrome, en plus de Firefox 3. Autrement dit, en l'état actuel des choses, un tel outil ne peut pas être considéré comme accessible : que dire des utilisateurs d'autres navigateurs, comme Opera ou, surtout, Internet Explorer (ce dernier étant le navigateur le plus couramment utilisé non seulement par les utilisateurs physiquement valides, mais aussi par bon nombre d'utilisateurs de lecteurs d'écran, qui se basent sur un navigateur) ?

D'ailleurs, pourquoi mener une expérimentation en laboratoire alors qu'on peut d'emblée améliorer l'accessibilité de la page des résultats de recherche telle que la plupart des utilisateurs connaissent, à savoir celle par défaut ? Il est vrai qu'il y a du pain sur la planche (même si l'agrandissement de la taille de police est possible), surtout si l'on se met à examiner le code source généré, qui est tout sauf respectueux des standards , et comme une page conforme aux standards marque déjà de précieux points pour son accessibilité…

Accessibilité des sites Web de Luc Van Lancker : note de lecture

Victor Brito — Mon, 22 Sep 2008 22:42:00 +0200

Les éditions Eni viennent de publier Accessibilité des sites Web - Mise en œuvre des directives WCAG 1.0, de Luc Van Lancker.

Ceux qui se soucient déjà d'accessibilité n'apprendront pas grand'chose en lisant ce livre. Néanmoins, il convient parfaitement aux webmestres, intégrateurs, développeurs et autres acteurs du Web qui souhaient s'initier à l'accessibilité du Web. Il prend soin, en effet, de présenter les différents handicaps qu'on peut rencontrer parmi les internautes potentiels, ainsi que les différentes aides techniques (là-dessus, il est dommage que l'auteur ne dise rien sur les synthèses vocales pour les systèmes autres que Windows, comme VoiceOver pour Mac OS X, sans oublier les outils d'accessibilité proposés par des navigateurs comme Opera).

Ensuite, chaque chapitre abordant le vif du sujet est illustré d'exemples permettant d'appréhender les techniques d'accessibilité, avec transcription de ce que peut lire une synthèse vocale (en l'occurence, Jaws). Toutefois, quelques erreurs et inexactitudes se glissent çà et là : l'élément q devient cite et le fait que les synthèses ignorent les feuilles de styles est inexact : si elles ignorent le choix des couleurs et des arrière-plans, par exemple, elles peuvent, en revanche, tenir compte d'une déclaration CSS comme display: none, sans oublier qu'on peut tout à fait produire une feuille de style destinée aux synthèses vocales et aux plages braille, grâce aux médias aural (speech en CSS 2.1) et braille, respectivement (encore faut-il que les aides techniques implémentent ces types de média et les propriétés CSS qui leur sont spécifiques, cela s'entend toujours ).

La fin de l'ouvrage récapitule les points de contrôle de WCAG 1.0, les critères Accessiweb et ceux du RGAA et compare, surtout, quelques validateurs d'accessibilité, pour mieux démontrer que la plupart de ces derniers peuvent ne valider que du vent et que rien ne vaut les vérifications manuelles. Pour finir, on trouvera quelques mots sur les moyens de certifier un site accessible, notamment la procédure en vigueur pour l'obtention du label Accessiweb.

Savoir en quelle langue est rédigé le contenu : l'exemple des sites multilingues

Victor Brito — Sat, 06 Sep 2008 18:34:00 +0200

Le blog officiel pour webmasters de Google a publié le mois dernier un billet sur la manière de commencer un site multilingue. Ce billet prodigue des conseils pratiques du point de vue du référencement. Toutefois, il y a un conseil supplémentaire à ajouter et qui rend bien service non seulement aux moteurs de recherche dans leurs tris, mais aussi à certaines aides techniques, comme les synthèses vocales, afin d'éviter que ces dernières ne lisent le contenu comme une vache espagnole) : déclarer dans le code source (qu'il soit généré ou en dur) la langue de chaque page du site.

Pour cela, en HTML, il suffit de renseigner l'attribut lang dans l'élément racine html. Pour une page HTML rédigée en français, on aura :

<html lang="fr">

En XML, c'est l'attribut xml:lang qui joue ce rôle.

On peut égalemet envoyer une en-tête HTTP indiquant la langue de la page, ce qui, en HTML, est effectué comme suit :

<meta http-equiv="Content-Language" content="fr">

En XHTML, on n'oubliera pas, bien entendu, le principe de fermeture de tous les élements, y compris les éléments vides :

<meta http-equiv="Content-Language" content="fr" />

Il est également possible d'envoyer une telle en-tête au moyen d'un langage de programmation côté serveur, comme PHP :

<?php
header ('Content-Language: fr');
?>

Qui dit site multilingue dit site susceptible de fournir un même contenu (page, catégorie, article, billet, brève…) en plusieurs langues. Le HTML offre un balisage suffisamment riche pour signaler à l'agent utilisateur (dont les robots des moteurs de recherche) que la page actuellement consultée est disponible en d'autres langues. Pour le cas d'une URL comme http://fr.exemple.com/1, on peut fournir le code suivant :

<link rel="alternate" href="http://en.exemple.com/1" hreflang="en" lang="en" title="English version of the page" />
<link rel="alternate" href="http://es.exemple.com/1" hreflang="es" lang="es" title="Versión española de la página" />

Parallèlement, l'utilisateur humain doit être renseigné de ces équivalences :

<p><a href="http://en.exemple.com/1" hreflang="en" lang="en" title="English version of the page" >English</a> - <a href="http://es.exemple.com/1" hreflang="es" lang="es" title="Versión española de la página" >Español</a></p>

Comme le montrent les deux derniers exemples, en cas de changement de langue au sein d'une même page, il faut aussi renseigner la langue de la portion de contenu en langue étrangère (avec le même attribut lang, ou xml:lang dans le cas du XML), sous peine qu'un synthèse vocale ne la lise comme si elle était rédigée dans la langue principale du contenu, autrement dit comme une vache espagnole.

Pour approfondir

Voici une suggestion de liens permettant d'approfondir les propos de ce billet :

Un annuaire de sites accessibles

Victor Brito — Wed, 03 Sep 2008 21:26:00 +0200

Le site Handicap Zéro propose, parmi ses rubriques, un annuaire des sites accessibles.

Il s'agit d'un annuaire original non seulement pour la thématique abordée (les sites accessibles), mais surtout pour le fait que le formulaire de soumission d'un site n'est pas destiné aux webmasters qui souhaitent référencer leurs sites dans les annuaires : en effet, si la première partie du formulaire ressemble à un formulaire classique de soumission d'un site à un annuaire Web, la seconde partie, en revanche, invite l'utilisateur à noter le site proposé (de 0 à 5) et à commenter son expérience en matière d'accessibilité.

Autrement dit, c'est un très bon outil pour quiconque cherche des exemples de sites accessibles (pour chaque site référencé, on peut consulter les notes et commentaires laissés par les utilisateurs ; il y a même un classement des sites les mieux notés). En revanche, côté référencement, il est à améliorer : en effet, les liens qui pointent vers les sites référencés ne sont pas des liens en dur ; qui pis est, il s'agit de redirections 302, ce qui signifie que les sites référencés ne bénéficient pas de lien retour depuis l'annuaire. Dommage !

Si votre site n'est pas accessible, la justice pourra vous le rappeler

Victor Brito — Thu, 28 Aug 2008 22:41:00 +0200

Bon nombre de concepteurs de sites, d'agences Web et de clients d'agences Web n'ont pas encore pris la pleine mesure de l'importance de l'accessibilité du Web au plus grand nombre d'utilisateurs, quels que soient les handicaps rencontrés. Peut-être se disent-ils que, puisque rien, pas même une loi, ne les y oblige, ils peuvent ignorer certaines catégories d'utilisateurs en toute impunité, pour ainsi dire. Et pourtant…

Des propriétaires et autres responsables de sites Web ont déjà connu le banc des accusés d'une cour de justice et ont même été condamnés pour le délit suivant : leurs sites Web n'étaient pas accessibles à certains utilisateurs souffrant de handicaps physiques.

Le premier cas connu d'un procès se soldant par une condamnation pour inaccessibilité d'un site est celui intenté par Bruce Maguire, un internaute australien non voyant, envers le Comité d'Organisation des Jeux Olympiques de Sydney, qui, en 2000, fut condamné à dédommager Bruce Maguire, moyennant 20 000 dollars australiens. C'est ce que rapporte Webyboom, qui renvoie à l'analyse de Joe Clark.

Tout récemment, la NFB a gagné un procès contre Target.com, une chaîne de supermarché en ligne (une synthèse de ce procès est disponible), procès intenté à la suite d'une plainte initiale déposée par Bruce Sexton. Le jugement est édifiant :

La justice vient de les condamner, notamment, à mettre le site en conformité avec les recommandations de la NFB, d'ici au 28/02/2009 ; à financer sur 3 ans l'intervention de la NFB sur le site (pour 170 000 $, plus les frais de formation) ; et à verser jusqu'à 7 000 $ de réparations par plaignant, pour un total pouvant atteindre 6 millions de dollars. À ajouter à ces amendes, bien entendu les frais d'avocats, probablement conséquents, et surtout, à court terme, les dégâts commerciaux causés par cette publicité négative. Pour caricaturale qu'elle soit, l'image de la grande méchante world-company cynique, qui mégotte sur l'investissement pour permettre l'accès aux aveugles, est facile à véhiculer. Et elle le sera sans nul doute.

À cela il faut ajouter que Target devra verser 20 000 dollars à une association à but non lucratif créée par Bruxe Sexton, dans le but d'ouvrir un centre d'entraînement et de rééducation pour aveugles en Californie.

Certains y verront deux exemples d'une manie anglo-saxonne pour les procès intentés pour un oui ou pour un non et se diront que cette manière de « dérive » ne se produira jamais en France. Qu'ils se détrompent ! Bon nombre de pays adoptent des législations qui facilitent, voire imposent, l'accessibilité des services aux handicapés, jusques et y compris dans le domaine du Web. La France n'est pas totalement étrangère à ce mouvement, de par la loi du 11 février 2005, dont l'article 47 prévoit la conformité des sites Web des administrations et autres services de l'État, des collectivités locales et des établissements publics aux critères d'accessibilité du contenu du Web, notamment ceux du RGAA, qui a vu le jour pour atteindre ce but. Et le Plan Handicap Visuel (des extraits du communiqué de presse sont rapportés sur le blog) n'exclut pas l'hypothèse de sanctions à mettre en œuvre en cas de non-respect de la loi.

Et si l'on développe le site Web d'une société privée ou d'une association qui ne s'occupe pas de handicap ?, dira-t-on. Même si la loi vise principalement les services publics, il ne faut jamais dire qu'on sera toujours à l'abri d'un procès pour inaccessibilité. Après tout, c'est une question de discrimination ; et comme la loi en dit quelque chose et que nul n'est censé ignorer la loi…

Bref, ça ne coûte (presque) rien de rendre un site Web accessible, surtout si l'on y songe dès les premiers instants de la conception du projet de site Web ; en tout cas, ça coûte beaucoup moins que s'il fallait passer par la case tribunal.