Journal Accessiday 2014 : un évènement pour l'accessibilité du Web.

Sommaire

• • Accessiday en quelques mots.
  • Introduction.
  • L’accessibilité numérique, mais au fait, de quoi on parle ?
  • L’accessibilité des objets connectés.
  • L’accessibilité des applications web mobiles.
  • Les contrastes des textes.
  • Les techniques d’intégration d’icônes-liens.
  • Vous êtes tendance, vous êtes digital, vous connaissez ARIA ?
  • Javascript et accessibilité font-ils bon ménage ?

Accessiday en quelques mots.

L’évènement Accessiday est une rencontre autour de l’accessibilité du Web, organisée par des professionnel·le·s à destination des entreprises publiques et privées et du grand public. Cette première édition s’est tenue le 28 mai 2014, sur le Campus Effiscience de Colombelles en Normandie.

Voici un résumé de quelques conférences auxquelles j'ai pu assister. Les organisateurs ont annoncé qu’ils diffuseraient prochainement l’intégralité des diaporamas.

Introduction.

Par Vincent Louvet et Willy Leloutre.

Les politiques publiques ambitionnent aujourd’hui de réduire la fracture numérique, comme par exemple en Basse-Normandie. Or, selon Vincent Louvet, « on ne peut pas parler d’infrastructure sans parler des usages ».

Dans ce sens, IDEM Normandie est une action à destination des collectivités publiques pour former à la culture numérique, et par conséquent à l’accessibilité.

L’accessibilité numérique, mais au fait, de quoi on parle ?

Par Delphine Malassingne.

L’accessibilité fait partie de la démarche qualité web. Elle vise à « porter le contenu quel que soit le contexte ». Elle ne couvre donc pas spécifiquement les situations de handicap, et sert autant aux machines qu’à la navigation nomade.

Quelques chiffres sur les populations particulièrement ciblées (pour la France en 2013) :

• les séniors : 20 millions ;
• les personnes en situation de handicap : 12 millions ;
• les daltoniens : 3 millions ;
• les mobinautes : 32 millions.

Malassingne précise que 100% des utilisateurs peuvent être confrontés à une panne matérielle, et par conséquent sont ciblés par l’accessibilité. En outre, la loi peut favoriser cette démarche : par exemple, selon la loi du 11 février 2005 pour l’égalité des droits et des chances, une offre d’emploi non-accessible aux aveugles est discriminatoire.

Malassingne insiste sur la distinction entre accessibilité technique (le code) et accessibilité des contenus. Dans tous les cas, l’accessibilité est incrémentielle, toujours à renouveler. Dès lors, un site en voie d’accessibilité peut et doit être mis en ligne. Plus encore, il faut penser l’accessibilité en amont du processus de production : ainsi, lors de la discussion, on a rappelé que le coût de la non-qualité est supérieur au coût d’accès à la qualité. C’est un investissement à long terme, vers des utilisateurs souvent délaissés et donc potentiellement fidèles.

L’accessibilité des objets connectés.

Par Sophie Drouvroy.

L’Internet des objets (IdO), baptisé Web 3.0, est l’extension d’Internet à des objets du quotidien et à l’univers domotique. Microsoft, Google et Apple représentent aujourd’hui 85% du marché de l’IdO. L’IdO ne cible pas spécifiquement les « geeks » : 25% des Français possèdent au moins un objet connecté et 84% les voient comme un progrès. En outre, l’IdO est l’un des plans d’avenir du gouvernement.

L’accessibilité des objets connectés est donc indispensable. Drouvroy souligne qu’il faut la penser maintenant, puisqu’en 20 ans, le Web n’est toujours pas accessible.

L’accessibilité des applications web mobiles.

Par Sébastien Delorme.

La certification d’accessibilité (ex : Accedeweb, RGAA…) n’est pas un gage d’utilisabilité. De leurs côtés, les tests automatisés demeurent des outils au service d’une démarche toujours manuelle et individualisée. En outre, il est nécessaire de faire des tests utilisateurs cadrés. Aujourd’hui, la BBC propose un référentiel pour les sites et applications mobiles : BBC Mobile Accessibility Guidelines (en).

Delorme a mis en avant la notion de désambiguation : un élément de désambiguation permet à l’utilisateur de ne pas être pris en défaut par une fonctionnalité inaccessible mais nécessaire (ex : une liste déroulante, masquée par le clavier virtuel) ou un contenu ambigu (ex : un texte Dérouler qui sonne comme Déroulé lorsqu’il est lu avec un lecteur d’écran).

Delorme donne aussi l’exemple d’un progiciel français ayant manqué des appels d’offre à l’étranger, à cause de son manque d’accessibilité. Or, en améliorant l’accessibilité pour s’imposer à l’étranger, il a consolidé sa présence sur le marché français.

Les contrastes des textes.

Par Nicolas Hoffmann.

La conformité des contrastes n’est pas une condition suffisante pour l’accessibilité, mais elle est nécessaire. Néanmoins, il faut éviter les contrastes positifs trop forts (effet de halo, caractère agressif) ou négatifs (effet de tremblement chez les dyslexiques, fatigue oculaire en général).

Hoffmann souligne que la conformité des contrastes est simple à atteindre, alors qu’elle est déterminante pour l’utilisateur qui y est directement confrontée.

Les techniques d’intégration d’icônes-liens.

Par Johan Ramon.

Note : je préfère utiliser le mot « icone » au lieu d’« icône ».

La technique classique est d’utiliser une image dans un lien. Les bugs connus sont :

• le texte alternatif (alt) qui ne peut excéder les dimensions intégrées dans le HTML ;
• l’absence de texte alternatif sous Chrome et d’autres cas isolés ;
• les images en background qui sont affectées par le mode de contraste élevé du système d’exploitation. Le problème peut être contourné en Javascript (par une détection du contraste élevé) ou avec CSS (avec list-style-image ou encore ::before content).

On peut aujourd’hui utiliser des icones faites avec des caractères. On peut associer un texte à chaque symbole ambigu, mais le mieux est d’accompagner l’icone d’un texte à cacher. Pour rappel, le texte caché avec display ou visibility ne sera pas lu par le lecteur d’écran, mais on peut utiliser opacity. Pour Ramon, l’idéal est de masquer le texte d’accompagnement de l’icone avec la fonte Adobe Blank (en). Parallèlement, pour ne pas lire le caractère utilisé pour l’icone, on peut utiliser l'attribut aria-hidden=true. Il existe une solution CSS speak:none; mais qui n’est pas supportée.

Selon Ramon, la solution d’avenir de l’icone-lien est SVG.

Vous êtes tendance, vous êtes digital, vous connaissez ARIA ?

Par Aurélien Levy.

ARIA (en) a été développé à l’origine par IBM pour associer ses solutions à l’environnement Web. Malgré l’usage d’ARIA, il faut privilégier la sémantique HTML et rester utilisable au clavier. À l’inverse, ARIA peut améliorer une mauvaise structure HTML via Javascript.

Il existe des valeurs ARIA similaires à des attributs HTML 5 (ex : hidden et aria-hidden). Néanmoins, leurs comportements ne sont pas forcément identiques, et les lecteurs d’écran ne supportent pas toujours ces attributs HTML 5.

Les rôles de type « landmarks » définissent de grandes zones de la page. Il ne faut pas en abuser, ni signaler une zone qui n’a pas de contenu significatif dans la page (banner pour un simple titre/logo, par exemple) car un lecteur d’écran les listera à l’utilisateur.

En ce qui concerne les images, l’attribut alt vide évite aux lecteurs de lire le nom du fichier en cas d’absence de texte alternatif. Aujourd’hui, role=presentation permet de marquer une image à ne pas lire.

Javascript et accessibilité font-ils bon ménage ?

Par Stéphane Deschamps et Matthias Dugué.

Les intervenants ont montré que Javascript ne détériore plus l’accessibilité, et peut même y contribuer. Quelque soit l’usage du langage, « il faut vouloir être accessible pour l’être » (Stéphane Deschamps). Le client doit donc être sensibilisé à l’accessibilité et accompagné par le développeur.

Les intervenants ont aussi insisté sur l’existence de fonctionnalités natives de HTML, qui sont accessibles et ne nécessitent ni Javascript ni ARIA (tabindex par exemple).