Suivre Planète Accessibilité sur Twitter S'abonner à Planète Accessibilité (Flux de Syndication R.S.S)

Planète Accessibilité

La fraîche actualité de l'accessibilité Web

Consultation des 10 derniers articles

passer en mode liste

Les bonnes pratiques en faveur de l'accessibilité du festival des Eurockéennes

Gros amateur de musique mais aussi d'accessibilité, j'ai sous titré cette vidéo résumant le travail effectué par le Festival des Eurockéennes en la matière.

J'avais entendu parler de la démarche d'accessibilité numérique effectuée par les Eurockéennes lors de la création de leur site web pour l'édition 2014.

En fait, c'est à travers la prise en compte des critères qualité du référentiel Opquast que le site propose notamment une navigation efficace agrémentée de liens d'accès rapides, un balisage sémantique approprié.

A noter que Gaëtan Roussel était nommé "Parrain de l'accessibilité aux Eurockéennes" ; on le voit intervenir dans la vidéo ci-dessous.

La vidéo sous-titrée : "Eurocks Solidaires ! - Culture Pour Tous"

Accessibilité et bénéfices induits: petite mise au point

Le bouillonnant et talentueux Nicolas Hoffmann vient de publier un article intitulé Pour en finir avec les bénéfices induits de l’accessibilité. Dans ce billet, que je vous invite à lire, Nicolas évoque la question vieille comme l’accessibilité des bénéfices induits. Sujet très … La suite

Svg, liens et lecteurs d’écran

Cette page présente des résultats de tests du support, par des couples navigateur/lecteur d’écran, de balises et attributs visant à rendre accessibles des <svg> intégrés dans des <a>. Chaque technique présentée ci-dessous est accompagnée de l’exemple ayant servi de test, … Lire la suite

A propos des tests utilisateurs en accessibilité

Cela fait un moment que traîne l’idée d’un billet sur les tests utilisateurs, dans ma pile « articles à écrire dans pas longtemps », qui est haute comme ça et dont certains items ont 3 ans. Un article paru sur le site … La suite

Le RGAA bientôt mis à jour

Le Référentiel Général d'Accessibilité pour les Administrations va enfin connaître une remise à niveau après presque 5 ans de bons et loyaux services, avec notamment une prise en compte des standards HTML5 et WAI-ARIA. Tous les détails sur le blog d'Armony Altinier.

Voir en ligne : http://armonyaltinier.fr/index.php?...

Embarquement immédiat avec V-Technologies

Si tu es, ou si tu connais bien, quelqu’un qui a fait le choix de faire métier de l’accessibilité numérique, tu sais que c’est plus qu’un job. C’est un engagement ; la traduction économique et sociale d’une conviction. Et lorsqu’on a … La suite

Respecter les techniques WCAG ou pas telle est la question ?

Après l’annonce que Accessiweb HTML5 allait servir de base au nouveau RGAA v3, j’aimerais sortir mon blog d’entre les morts (la dernière publication datant d’il y a 3 ans) et prendre quelques instants pour revenir plus longuement sur la base technique de ce futur RGAA à savoir le référentiel Accessiweb HTML5.

La genèse d’Accessiweb HTML5

Ce référentiel a été mis au point dans sa très grande majorité par l’association Braillenet aidé en cela par Jean Pierre Villain de Qelios. Son élaboration fait suite à l’adaptation de son processus de certification à l’environnement HTML5. Une fois le travail préparatoire effectué un collège d’experts référents a été sollicité à trois reprises sur le document :

  • octobre 2012 sur une série de grands principes
  • puis en mai et juin 2013 sur les thématiques.

Ces personnes sont d’ailleurs listées et remerciées tout en bas de la page présentant ce nouveau référentiel.

Les échanges ont eut lieu par le biais d’un forum et pour ce qui me concerne n’ayant pas eu le temps de faire de retours techniques je m’étais attaché à ce moment là à soulever des interrogations de fond qui pour certaines sont malheureusement restées sans réponses.

Ce référentiel a ensuite été présenté lors d’un séminaire au travail Accessiweb en décembre 2013. Suite à quoi plusieurs échanges ont également eut lieu sur la liste du groupe de travail. C’est la version présentée lors de ce séminaire qui est toujours présente sur le site d’Accessiweb comme la version à jour et qui servira très probablement de base technique au RGAA3. On trouve notamment dans le document la mention :

« Ce document est le document de travail présenté lors du séminaire GTA le 19/12/2013. Il sera prochainement versionné. »

De la complexité des WCAG 2.0 et de l’usage des techniques

Comme vous le savez sans doute déjà le référentiel Accessiweb se veut un moyen permettant de vérifier la conformité au standard international WCAG 2.0. En cela, il est composé d’une série de tests faisant référence aux différents critères de succès ainsi qu’aux techniques suffisantes (sufficient techniques) et aux échecs (failures) de WCAG 2.0. Les techniques suffisantes et les échecs, bien que n’étant pas normatives constituent la référence permettant de juger de la conformité d’un critère au sein de nombreuses législations (et sans doute notamment pour la future législation européenne). En particulier l’ensemble des échecs référencés me semblent devoir être parfaitement pris en compte et respectés dans toutes les méthodes vérifiant formellement la conformité aux WCAG.

Accessiweb HTML5 allant servir de base au nouveau RGAA et donc devenir la nouvelle référence officielle, il me semble opportun de faire une petite analyse comparative de la prise en compte des techniques WCAG au jour d’aujourd’hui dans le référentiel. Encore une fois, il s’agit dans l’ensemble d’un très bon document que je vous invite à utiliser dès maintenant, les éléments qui vont suivre tenant plus de l’analyse de texte chirurgical que d’un jugement de qualité sur le document.

Par ailleurs, cette liste bien évidemment n’a pas la prétention d’être exhaustive. Elle n’est que le résultat de ce que j’ai pu relever à titre personnel depuis décembre 2013 au cours de mes activités.

Les experts parlent aux experts

Attention ce qui suit va vous plonger dans les méandres des WCAG et d’Accessiweb, je ne saurais être tenu responsable des dommages que cela pourrait engendrer dans votre productivité.

  • Les techniques WCAG ne donnent pour l’instant aucune information quand à l’usage des nouveaux éléments ou attributs HTML5 hormis sur le wiki de travail de WCAG en version préparatoire. Le référentiel Accesiweb HTML5 fixe quant à lui les règles d’usage de certains de ces éléments notamment les éléments header, nav, main, footer (cf critère 9.2 et sa note technique) mais également des éléments figure, figcaption (cf critère 1.10) ou complète des critères existants par des tests spécifiques sur l’élément canvas ou par l’élargissement de la définition de média temporel. Enfin il donne également des règles à suivre sur les nouveaux attributs tel que track (cf critère 4.3) ou les attributs de formulaire HTML5 date, time, tel, number, range, email, search, required. (cf critère 11.10).
  • Les techniques WCAG interdisent l’usage du role presentation sur des éléments ayant une valeur sémantique devant être restituée. C’est ce qu’indique l’échec F92. À l’inverse ils l’autorisent sur ceux dont la sémantique ne devrait pas être restituée (exemple sur un élément blockquote qui aurait été utilisé pour faire de la mise en forme) cf échec F43. Je n’ai pas trouvé de correspondance dans Accessiweb HTML5.
  • Les techniques WCAG autorisent l’usage des attributs title, aria-label ou aria-labelledby sous certaines conditions pour donner une alternative à une image (cf échec 65). Le critère AW/HTML5 1.1 prévoit l’usage de l’attribut alt comme seul moyen permettant de restituer une alternative à une image.
  • Les techniques WCAG autorisent l’usage du role presentation au regard de l’échec F38 pour masquer une image aux aides techniques. Le critère AW/HTML5 1.2 prévoit l’usage d’un attribut alt="" sur les images de décoration comme seul moyen pour masquer une image aux aides techniques.
  • Les techniques WCAG laissent librement le choix entre différentes techniques tel que G14 et G182 pour donner un moyen d’accès à l’information autre que la couleur. Le critère AW/HTML5 3.2 juge de la pertinence de ce choix.
  • Les techniques WCAG imposent la présence d’un élément caption si un titre de tableau est visuellement présent dans la page au regard de la technique h39. Le critère AW/HTML5 5.4 impose l’usage d’un élément caption dans tous les cas.
  • Les techniques WCAG autorisent l’usage de simple td avec un attribut scope ou des role rowheader ou columnheader pour signaler des entêtes de lignes ou de colonnes au regard de la l'échec F91. Le critère AW/HTML5 5.6 impose l’usage d’éléments th.
  • Les techniques WCAG autorisent le recours à aria-label ou aria-describedby pour restituer des informations de contexte sur l’intitulé d’un lien via l’échec F63. Le critère AW/HTML5 6.1 ne le prévoit pas.
  • Les techniques WCAG demandent à ce que les listes simulées visuellement soit balisées comme telles (via (ol / ul notamment) au regard de la procédure de test H48. Le critère AW/HTML5 9.3 impose l’usage des éléments de listes sur tous les éléments de listes sans définition de ce qu’est une liste (est-ce qu’une suite d’actualités (image + titre + intro + lien) balisée à l’aide de titres de hiérarchie est également une liste ?).
  • Les techniques WCAG notamment la technique C30 demandent en complément d’une image de fond porteuse d’information et d’un texte masqué via css d’avoir un bouton pour désactiver cette solution et avoir accès au texte. La procédure de test de l’échec F3 indique quant à elle que l’information doit être disponible même quand l’image css n’est pas affichée " the information is provided to assistive technologies and is also available when the CSS image is not displayed." Le critère AW/HTML5 10.2 autorise par le biais du terme "contenu visible" du glossaire l’usage de texte masqué seul pour rendre accessible une information rendue visible par le biais d’une image de fond.
  • Les techniques WCAG n’interdisent pas explicitement l’usage du pixel pour dimensionner un texte. L’échec F80 vise explicitement les contrôles de formulaire. L’échec F69 vise le cas de perte d’informations quand on agrandit le texte (avec les pixels dans certains cas ils ne s’agrandit pas donc le point ne peut s'appliquer) c'est le mix taille de bloc fixe / taille du texte qui s'agrandit qui est problématique. La technique G179 concerne également le cas quand on agrandit le texte par rapport aux tailles de blocs fixes. Enfin, les techniques C12, C13 et C14 s'appliquent uniquement quand on utilise également un dimensionnement relatif des blocs "Ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques" (le AND est en gras dans les sufficient techniques for 1.4.4). Par ailleurs, les solutions de recours au zoom du navigateur ou à des boutons d’agrandissement ne sont pas prises en compte dans Accessiweb HTML5 (G142 et G178) bien que faisant explicitement partie de techniques suffisantes. Le critère AW/HTML5 10.4 interdit l’usage du pixel pour dimensionner le texte.
  • Aucune technique WCAG n’autorise l’utilisation de title ou d'ARIA sur les inputs submit. Le critère AW/HTML5 11.9 autorise leur utilisation.

et maintenant ?

Comme je l’ai dit précédemment tout cela ne fait pas d’Accessiweb HTML5 (et donc du futur RGAA) un mauvais référentiel sur le fond technique. Il s’agit pour la plupart des cas de contraintes imposant plus de restrictions aux concepteurs / développeurs mais cela est fait aux bénéfices de l’utilisateur donc elles ne sont effectivement pas forcément mauvaises en soi. J’espère que ces éléments illustrent bien par contre la complexité que peut représenter le « respect » des WCAG à 100%. Peut être certaines de ces observations auront-t-elles une utilité pour les personnes en charge de la mise à jour du RGAA ou d’Accessiweb

SEO en agence vs SEO chez l'annonceur

Faisant suite à la table ronde à laquelle j'ai eu le plaisir de participer lors du SMX Paris avec Béatrice Payonne et Mael Montarou , et ayant œuvré dans les deux mondes, je vous livre aujourd'hui ma réflexion personnelle sur les différences entre le SEO coté agence et le SEO coté annonceur, du point de vue du référenceur essentiellement. Mais les entreprises sauront également en tirer des enseignements ;)

Autant le dire tout de suite : aucune de ces positions n'est je pense meilleure qu'une autre dans l'absolu. Tout est question de contexte et d'affinité personnelle, chaque position ayant typiquement les défaut de ses qualités.

Avantages et facilités à être SEO chez l'annonceur

  • Un travail plus en profondeur, sur la durée.
  • Une connaissance plus complète du fonctionnement de l'entreprise et de son marché.
  • Des interactions avec avec une grande diversité d'acteurs (transversalité).
  • La possibilité d'évangéliser / former les autres acteurs.
  • Une large autonomie.
  • Souvent plus de moyens pour acheter outils et prestations (chez les gros annonceurs du moins).
  • Des salaire plus élevés (chez les gros annonceurs).
  • Une compréhension de pourquoi les recos des agences ne sont pas appliquées ;)

Inconvénients et difficultés à être chez l'annonceur

  • Des rythmes parfois lents (ce qui peut être un avantage : on a le temps pour réfléchir).
  • Une moindre diversité thématique.
  • Un certain isolement si on est seul (pas de discussions entre SEO. heureusement il y a les conférences et apéros divers).
  • La nécessité de connaitre un maximum d'intervenants pour faire avancer les choses.
  • Il faut parfois (souvent) se battre pour obtenir des implémentations.
  • La dimensions politique et les prés carrés de chacun.
  • La frustration quand des facteurs externes affectent négativement le SEO (par ex une réduction de l'offre).
  • Etre considéré comme un salarié parmi plein d'autres, pas comme un expert.

Avantages et facilités à être SEO en agence

  • Des rythmes plus rapides.
  • Une très grande diversité thématique : pas de monotonie !
  • Des tâches très variées (avant-vente, développement de produits, consulting, formation...)
  • Les échanges avec les autres collègues SEO.
  • On a en général un interlocuteur référent (pas besoin de connaître tout le monde).
  • Le fait d'être vu comme un expert par les clients (ça fait du bien à l'égo).
  • Facilité à aller dans les conférences SEO (car bénéfique pour l'agence).

Inconvénients et difficultés à être en agence

  • Des prestations parfois "fire and forget", qui ne sont pas implémentées.
  • Des prestations qu'on aimerait parfois travailler dans la durée.
  • Le manque de temps qui ne permet pas toujours d'aller aussi profond qu'on voudrait.
  • Une moindre connaissance des rouages des entreprises clientes.
  • Les plus gros salaires sont chez l'annonceur (mais tous les annonceurs ne paient pas bien et on peut être très bien payé en agence).

A lire également le sujet : les billets de Florian Bordet et Arnaud Mangasaryan, qui rejoignent sur bien des points ma propre expérience.

Titres de pages et accessibilité

En HTML, le titre d’une page web équivaut au contenu de la balise <title>. Élément qui doit être intégré dans l’entête du document, entre les balises <head> et </head>. Ce titre principal de la page n’est pas à confondre avec … Lire la suite

Quand l'outil de planification Adwords vous cache des mots-clés

L'outil de planification de Google Adwords est l'une des sources d'inspiration favorite des SEO. Un point trop rarement évoqué cependant est le fait que Google vous cache des mots-clés alors même que celui-ci possède bien des données à leur sujet.

Supposons par exemple que je vende des carrés en soie de la marque Hermès. Une recherche sur "carre hermes" dans l'outil de planification me donne 1300 recherches mensuelles (480 pour la version accentuée de la requête) :

suggestions-carre-1.jpg

Si je fais une recherche sur "carre" tout seul, en toute logique, l'outil devrait me remonter la requête "carre hermes" puisque celle-ci contient le terme "carré". En classant les requêtes par nombre de recherches mensuelles je devrais le trouver facilement puisque je connais son volume. Or ce n'est pas le cas :

suggestions-carre-2.jpg

Ne croyez donc pas qu'en faisant une recherche sur un terme "X" l'outil de planification Adwords va vous retourner l'ensemble des requêtes contenant le terme "X". Vous n'aurez droit qu'à un échantillon, pas forcément représentatif.

Pour une recherche en profondeur sur une thématique, il est donc primordial d'alimenter l'outil de planification avec d'autres termes que le terme principal. Ces termes additionnels pouvant être déterminés à partir de votre offre, de vos données de trafic, d'un brainstorming, de suggestions précédentes de l'outil de planification, de Google suggest (via Ubersuggest) etc... A vous d'être créatifs :)