L’accessibilité du Web.

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

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é 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 moyens sur les populations particulièrement ciblées (pour la France en 2013) :

• les séniors : 15 millions ;
• les personnes en situation de handicap : 10 millions ;
• les presbytes : 20 millions ;
• les daltoniens : 5 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’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.

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 (exemple : une liste déroulante, masquée par le clavier virtuel) ou un contenu ambigu (exemple : un texte Dérouler qui sonne comme Déroulé lorsqu’il est lu avec un lecteur d’écran).

Delorme évoque aussi le cas 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.

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.

• 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 icônes faites avec des caractères. On peut associer un texte à chaque symbole ambigu, mais le mieux est d’accompagner l’icône d’un texte à cacher. Pour rappel, le texte caché avec display ou visibility ne sera pas lu par le lecteur d’écran. On peut utiliser opacity. Pour Ramon, l’idéal est de masquer le texte d’accompagnement de l’icône avec la fonte Adobe Blank (en). Parallèlement, pour ne pas lire le caractère utilisé pour l’icône, 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’icône-lien est SVG.

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 (hidden et aria-hidden, par exemple). 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.

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