Objectifs
Problèmes et solutions possibles
L’objectif de cette étude est de relever les principaux problèmes d’accessibilité de Google Maps dans un contexte d’intégration du service dans un site Web.
Pour chaque potentiel obstacle à la consultation relevé, des propositions de correction et des pistes d’amélioration seront proposées.
Cette étude a donc pour intention de recenser et de centraliser des solutions ou des contournements pour palier à certains problèmes d’accessibilité inhérent à l’intégration du service dans un site Web.
Une étude accessible et profitable à tous
Accessible au sens compréhensible
Cette étude se veut abordable et compréhensible pour tous les acteurs de la réalisation d’un site Internet ; du chef de projet au contributeur, en passant par le graphiste et le développeur.
Cette étude est donc parfois technique, parfois plus théorique ; mais les conseils et solutions préconisées sont "vulgairement" présentés dans l’optique d’être aisément applicables.
Profitable au sens utile
Le but de ce document est qu’il puisse servir de repère à tous les intervenants qui seraient amenés à vouloir implémenter la solution Google Maps de façon accessible au sein d’un site Internet.
Commanditaire - AMOA
Ce document peut être utile aux commanditaires ou aux personnes en charge de l’assistance à maîtrise d’ouvrage.
Ils peuvent s’y référer pour faire figurer dans leur cahier des charges, leurs exigences quant à l’implémentation accessible de Google Maps au sein de leur projet Web.
Ergonome - Concepteur d'interface - Designer
Ce document peut être consulté au moment de la conception de Zonings, Wireframes et autres prototypes afin de ne pas omettre certains éléments essentiels à l’accessibilité.
Cette étude informe également sur les possibilités en termes de personnalisation graphique de la solution ; ce qui peut s’avérer être intéressant au moment de la phase de maquettage graphique.
Chef de projet - AMOE
Ce document peut être utile aux chefs de projet ou aux personnes en charge de l’assistance à maîtrise d’œuvre.
Ils peuvent s’y référer pour faire figurer, dans leur cahier des spécifications fonctionnelles et techniques à destination des équipes techniques, leurs exigences quant à l’implémentation accessible de Google Maps au sein de leur projet Web.
Technicien
Cette étude étant en partie un recueil de solutions et de ressources techniques visant à améliorer l’accessibilité native de Google Maps, il peut servir de base de travail pour les développeurs soucieux de cette problématique.
Présentation de Google Maps
Google Maps est un service gratuit de cartographie en ligne qui a été lancé par Google en 2004. Il a été rendu exploitable en France en avril 2006.
Site Internet de Google Maps
.
Le service est utilisable grâce à une simple connexion Internet couplée à un navigateur Web.
De nombreuses fonctionnalités
Plan interactif
Google Maps permet de naviguer et de se positionner où l'on veut sur une carte.
Il permet, à partir de l'échelle d'un pays, de pouvoir zoomer jusqu'à l'échelle d'une rue.
Plusieurs types de vue sont disponibles : une vue en plan classique (avec nom des rues, quartier, villes), une vue en image satellite et une vue mixte étant un mélange des deux premières citées.
Aujourd'hui, Google Maps couvre le monde entier.
Points d’intérêt et calcul d’itinéraires
L’API Google Maps propose des fonctionnalités avancées comme la recherche de lieux et d’adresse ou encore le calcul d’itinéraires piéton ou routier.
Il est possible de paramétrer de nombreuses options et filtres de recherche afin d’affiner de façon optimal ces différentes requêtes et résultats de recherche associés.
En plus de localiser l'endroit recherché, Google Maps peut, pour une entreprise ou une autre entité, afficher des informations telles qu’un numéro de téléphone public, ou l’adresse d’un site Internet.
Autres fonctionnalités
Depuis quelque temps, Google Maps propose d’autres outils, en voici une liste non exhaustive :
- "Street View" qui permet d'afficher des photos dans certaines grandes villes ;
- "Trafic" et son calcul de la circulation routière en temps réel ;
- "Météo" ; etc.
Google Maps ne cesse d’évoluer et de lancer de nombreuses nouvelles fonctionnalités pour la plupart facilement intégrables et paramétrables au sein d’un site Web.
De multiples usages
Aujourd’hui, le WebMapping est devenu une facette incontournable du Web.
De plus en plus de sites Internet incluent leur propre service de cartographie interactive :
- Géolocalisation d'un lieu sur le site du forum sur l'accessibilité à Francfort
; - Géolocalisation d'individus à travers le monde sur le site "Alsacréations"
; - Recherche et affichage de points d'intérêts sur le site de la ville d’Hautmont
; - Calcul d'itinéraires sur le site de ville de Rezé
.
Les raisons de son succès
Avec la mise à disposition au public d'un outil lui permettant de visualiser, par photo satellite, le monde entier de manière précise, le projet a rencontré un véritable succès.
L'API Google Maps est l'une des applications de cartographie interactive les plus utilisées au monde.
Possibilités et simplicité d’utilisation
Comme la majeure partie des produits estampillés Google, le service est (toute proportion gardée) extrêmement simple d'utilisation.
Les fonctionnalités mises à disposition, comme la possibilité de créer ses propres cartes ainsi que de les exporter où bon nous semble dans un site, sont relativement facile à implémenter.
De plus, la toile regorge de ressources (sites Web dédiés) et d’échanges traitant du sujet et de sa mise en œuvre.
La communauté autour de Google Maps est importante et réactive.
Liberté de personnalisation
L’intégration du service dans un site Web laisse une grande marge de manœuvre quant à la personnalisation de l’outil.
Il est par exemple possible de modifier l’aspect graphique des composants originels suivant :
- Les fonds de cartes ;
- Les boutons de contrôle (déplacement, zoom, choix du type de carte) ;
- Les marqueurs des points géolocalisés.
Nous verrons par la suite que toutes ces possibilités de personnalisation peuvent être bénéfiques à l'amélioration de l'accessibilité et au confort d’utilisation du service.
Compatibilité et interopérabilité
Le service Google Maps propose plusieurs types d’API
.
L’API Google Maps standard est basé sur des langages de programmation libre (HTML, CSS, JavaScript) ce qui favorise son "interopérabilité multiplateforme".
Cette dernière est compatible et stable sur les principaux navigateurs du marché :
- Internet Explorer ;
- Firefox ;
- Chrome ;
- Safari ;
- Opéra ; etc.
Il existe plusieurs versions mobiles de Google Maps. Ils utilisent les réseaux des téléphones et des tablettes notamment 3G pour charger les cartes de la même manière que sur la version Internet.
Le service de base ne dépend donc pas d'une technologie propriétaire comme Flash.
Niveau performance, le service de cartographie Google Maps est (en fonction de la modernité de l’équipement de l’utilisateur) d'une rapidité très compétitive.
Autre atout majeur : de nombreuses synergies avec d'autres services Google existent et s'avèrent très pratiques.
Évolutivité et pérennité
Google a été l’un des précurseurs sur le marché à proposer un service complet de cartographie en ligne.
La solution est régulièrement mise à jour ; elle évolue perpétuellement.
La version actuelle de la Google Maps JavaScript API est la V3 (au 01 Septembre 2011).
Comme pour leurs autres produits, les équipes de la firme Google travaillent sans cesse à l’amélioration et à l’optimisation de leur solution de Webmapping ; la garantissant toujours plus stable et robuste.
Il y a peu de chance que le service et son développement ne soient abandonnés du jour au lendemain.
Navigation au clavier
Nativement, les commandes de la carte ne sont pas accessibles aux personnes utilisant exclusivement le clavier.
L’utilisation du service et de toutes ces fonctionnalités est tributaire de l'interaction avec la souris.
Se déplacer sur la carte, la zoomer ou encore changer de mode de présentation sont des actions qui ne peuvent être réalisées avec le clavier.
L’origine du problème est que ces boutons de contrôles sont codés avec des éléments <div> ; ces derniers ne pouvant recevoir le focus clavier.
À titre indicatif, en HTML, les seuls éléments qui peuvent recevoir le focus clavier sont :
- Les liens : balise
<a>; - Les zones image Map : balise
<area>; - Les éléments de formulaire : balises
<input>,<button>, etc.
Seuls les liens "Powered par Google" et "Conditions d'utilisation" situés tout en en bas de la carte peuvent être atteints avec la touche de tabulation.
Ces deux liens présentent tout de même d’autres problèmes d’accessibilité.
Le premier est que ces liens s’ouvrent dans une nouvelle fenêtre (présence de l’attribut target avec comme valeur _blank) sans que le changement de contexte ne soit explicité.
Ainsi, l’absence de l’information "Ouverture d’une nouvelle fenêtre" dans l’attribut alt pour l’image lien et l’attribut title pour le lien textuel est à déplorer.
L’autre problème d’accessibilité provient de la couleur des liens (Condition d’utilisation) qui n’est pas suffisamment contrastée avec les couleurs d’arrière-plan, celles du fond carte.
Ce problème a été constaté en utilisant l’outil de vérification des contrastes de couleurs "Colour Contrast Analyser
".
Instanciation de raccourcis clavier
La classe GKeyboardHandler
La classe GKeyboardHandler
permet de rajouter des raccourcis clavier à une carte.
Une fois implémenté, ce palliatif rend possible le zoom et le déplacement sur la carte avec le clavier :
- Zoom : touches + et - du pavé numérique ;
- Déplacement sur la carte : flèches directionnelles.
Cependant plusieurs problèmes persistent.
Pour que cette fonction soit opérationnelle, le problème est qu’il faille l’activer avec un clic sur la carte.
Cela s’avère être un non-sens, la personne naviguant exclusivement avec le clavier n’ayant jamais la possibilité d’activer ce patch.
Exemple d'instanciation de raccourcis clavier avec la classe GKeyboardHandler
.
La fonction Gevent
Le problème précédemment évoqué peut être résolu avec la fonction Gevent
.
Le principe de cette fonction est, qu’au moment du chargement du document et de la création de la carte, la classe GKeyboardHandler s’active ; et ce sans manipulation de l’utilisateur (clic sur la carte).
Ainsi, les raccourcis sont rendus opérationnels sans aucune action de l’internaute.
Cette solution, intéressante au premier abord, n’est pas exempte de tout inconvénient ; et plusieurs problèmes en termes d’accessibilité persistent.
Le premier étant que cette instanciation de raccourcis clavier n’est pas complète.
Seules les possibilités de zoom et de déplacement sur la carte sont offertes et il n’est toujours pas possible de changer de type de carte.
Les boutons "Plan", "Satellite" et "Mixte" ne sont toujours pas atteignables au clavier.
Il en est de même pour atteindre les potentiels marqueurs des points géolocalisés.
Exemple d'instanciation de raccourcis clavier avec la fonction Gevent ![]()
Un autre problème persiste. Ces nouveaux contrôles ne sont pas standards.
Par conséquent, ces raccourcis instanciés arbitrairement peuvent rentrer en conflit avec les configurations originelles du poste de travail de l’utilisateur.
Concrètement, ces raccourcis peuvent interférer avec les raccourcis clavier natifs des navigateurs graphiques ou autres aides techniques utilisés par l’internaute.
De plus, ces nouveaux contrôles n’étant pas standard, il serait nécessaire d’apporter des explications quant à leurs usages.
Surcharge du balisage
La solution la plus solide s’avère être de réparer les erreurs commises à la source.
Le code doit donc être rénové en surchargeant le balisage fournit initialement.
Pour rappel, l’origine du problème provient du fait que les boutons d’interaction de la carte ont été codés avec la balise <div> ; cette balise n’étant pas en mesure de recevoir le focus clavier.
La correction efficace de ce problème consiste donc à injecter du code dans ces éléments <div> ou simplement de les remplacer par la balise adéquate ; celle qui sera capable de recevoir le focus clavier.
La balise qui semble la plus approprié pour répondre aux exigences d’accessibilité est l’élément <button> ; <a> étant à utiliser de préférence pour la navigation entre les pages ou pour les ancres de navigation interne à une page.
En appliquant cette modification de réécriture du code, la structure et la sémantique du document se voit améliorées.
La mise en œuvre de ce correctif est expliquée sur le site de la communauté des développeurs d’Opéra.
Pour exemple, la page "Venue" du site du forum européen sur l’accessibilité numérique de Frankfurt
a utilisé cette solution sur sa carte de localisation.
Toutes les interactions sur la carte comme le déplacement ou son agrandissement sont alors rendus possibles ; et ce sans les problèmes qui persistaient avec les précédentes solutions présentées.
Toujours sur ce site, même si cela ne concerne pas directement le sujet de cette étude, je tiens à soulever une intéressante implémentation des liens rapides de navigation interne (liens d’évitement).
Au chargement de la page, les liens "Skip to content" et "Skip to navigation", qui apparaissent au fil de la navigation par tabulation, mettent en surbrillance la zone de destination par un contour en pointillés bleus.
Cette technique me paraît être une très bonne pratique et une façon optimale et intelligente de mettre en œuvre une recommandation en termes d’accessibilité.
Cela a pour avantage de faciliter la compréhension de la navigation pour les personnes utilisant le clavier.
Personnalisation des contrôles
L’API Google Maps laisse beaucoup de souplesse quant à la personnalisation des différents éléments graphiques composant la carte.
Les éléments de contrôles natifs peuvent être remplacés par ses propres compositions.
Il peut-être est judicieux de tirer profit de cette liberté de personnalisation afin d’améliorer l’ergonomie du service.
Dans cet exemple où les contrôles sont personnalisés
, les éléments interactifs permettant de changer de style de carte sont bien mis en évidence.
Ils sont de tailles plus importantes que les boutons d’origine, la zone réactive est donc plus étendue et le confort d’utilisation potentiellement amélioré.
(Note : cette remarque ne concerne pas directement l’accessibilité.)
Pour améliorer encore davantage l’expérience utilisateur et l’ergonomie de la fonctionnalité, il est concevable de marquer de façon significative l’effet visuel lors de l’activation des boutons de contrôle.
- Survol -
:hover; - Prise de focus -
:focus; - Activation du lien -
:active; - État actif - type de vue en cours de consultation.
On peut imaginer remplacer les boutons d’action standards du service par des boutons incluant des intitulés textuels clairs et plus explicites :
- "Déplacer la carte vers la droite" ;
- "Déplacer la carte vers la gauche" ;
- "Déplacer la carte vers le haut" ;
- "Déplacer la carte vers le bas" ;
- "Agrandir la carte".
L’exemple présenté sur le site votre-hotel.com
est une belle illustration des possibilités laissées en termes de personnalisation des boutons d’action.
Ici, l’utilisateur a la possibilité de basculer d’un pilotage du plan intégré à une interaction avec la carte externalisée (appelée mode accessible).
Les boutons d’action se placent alors sous la carte.
JavaScript et alternatives
La solution Google Maps et ces différentes fonctionnalités dépendent en grande partie du langage de programmation JavaScript.
Sans le support de cette technologie, il est impossible de consulter la carte ainsi que ces données (points géolocalisés) et par conséquent d’interagir avec eux.
Pour exemple, sur la carte interactive du site de la ville de Pierrefitte-sur-Seine
, en naviguant sans le support de JavaScript la carte n’est pas disponible.
Google Static Maps API
La Google Static Maps API
permet d'intégrer une image statique en remplacement de la carte dynamique.
Son utilisation consiste à fournir une solution de repli, un fallback pour les utilisateurs qui ne dispose pas de JavaScript activé dans leur navigateur.
De nombreux paramétrages et diverses options concernant l’affichage de cette image sont mis à disposition :
- Niveau de zoom ;
- Taille de l’image ;
- Format de l’image ;
- Type de carte (plan, satellite, mixte) ;
- Style du marqueur des points géolocalisés ; etc.
Exemple de mise en œuvre : Google Static Maps API sur la page "Venue" du site du forum européen sur l’accessibilité numérique de Frankfurt
.
Alternatives aux points géolocalisés
Dès lors qu’une carte interactive est proposée, il convient de fournir des alternatives textuelles aux points géolocalisés.
Ces alternatives doivent au minimum disposer de l’ensemble des données contenues dans les infobulles des points marqués.
La page "Plan de la ville" du site de la mairie d'Hautmont
propose des alternatives textuelles aux points géolocalisés en cas de non support de JavaScript.
Ces alternatives textuelles, devenues exploitables dans n’importe quel contexte, sont susceptibles d’être bénéfiques à toutes les personnes.
Aux personnes éprouvant des difficultés particulières à la consultation des informations des points géolocalisés :
- Personnes naviguant sans le support de JavaScript ;
- Personnes ayant une faible connexion Internet (bande passante limitée) ;
- Personnes aveugles ou déficientes visuelles ;
- Personnes atteintes de troubles cognitifs pour qui il peut être difficile d’appréhender la consultation d’une carte ;
- Personne naviguant au clavier ; etc.
Mais ces alternatives peuvent être tout autant bénéfiques aux personnes disposant de toutes leurs facultés et d’un équipement optimal.
Ces dernières préférant peut-être consulter des données textuelles simples, non représentées graphiquement.
À l’image du sous-titrage et des transcriptions textuelles pour les vidéos, les alternatives améliorent la compréhension de l’information pour tous.
Comment présenter les alternatives
En remplacement de la carte
Sur la page "Plan de la ville" du site de la mairie d'Hautmont
, dans un contexte de navigation sans le support de JavaScript, les alternatives textuelles remplacent la carte.
Cette pratique n’est pas optimale ; en effet, il ne faut pas oublier que les alternatives peuvent être utiles à tous et pas seulement aux personnes n’ayant pas accès à telle ou telle technologie.
Sur une page distincte ou en complément de la carte
Présenter l’alternative en complément de la carte permet de proposer deux moyens différents de consulter les informations.
La page "Nos interventions" du site de l'EFF IF
propose un système d’onglets qui permet de basculer d’une vue liste (textuelle) à une vue carte.
Les autres avantages des alternatives
Apport sémantique et optimisation SEO
Les données sont plus facilement manipulables, il devient alors plus facile d’apporter davantage de sens aux données.
Ainsi, une hiérarchisation de titres de section cohérente (<hn>) peut être adoptée ce qui d’une part favorise l’accessibilité et d’autre apporte un bénéfice important en terme de référencement.
Ces balises structurantes étant particulièrement appréciées des robots d’indexation.
Navigation au clavier
Contrairement à ce que propose l’API Google Maps, dans un contexte de navigation au clavier, une alternative avec une structure de données en HTML simple peut faciliter l’accès à la fiche complète d’un point géolocalisé.
Confort de lecture
Un listing linéaire des informations de tous les points marqués permet de servir une vue d’ensemble de l’information (résultats d’une recherche par exemple).
Cela permet notamment de réduire le nombre d’actions pour accéder à la version complète d’une fiche ; contrairement au système des tooltips proposé initialement par l’API.
De plus, cette présentation simplifiée supporte davantage un important agrandissement de la taille des caractères en mode zoom texte ce qui est une exigence en terme d’accessibilité.
Navigation sans le support des CSS
Dans un contexte de navigation sans l’interprétation des feuilles de styles, l’alternative textuelle simple se consulte aisément.
Ce qui n’est pas le cas sur la vue carte initiale où il est tout bonnement impossible d’accéder au contenu des points géolocalisés en cas de navigation sans le support des CSS.
Exploitation du contenu
Une représentation textuelle simple de l’information peut favoriser son exploitation sur d’autres supports.
Ainsi, les données peuvent correctement être imprimées ou générées au format PDF ou même plus facilement consultées depuis un terminal mobile.
Alternatives "enrichies"
Description de la carte
En complément et en amont de la carte interactive, il peut être pertinent de présenter son objectif et ses fonctions ; ce pourquoi elle est mise à disposition et ce qu’elle est susceptible d’apporter comme information.
Par exemple, de façon textuelle, avant d’afficher une carte présentant les départements touchés par les inondations, il peut-être perspicace d'en expliquer le contexte et les possibilités offertes en termes d’interaction :
- Délimitation géographique ;
- Date ;
- Fonctionnement du moteur de recherche ;
- Configuration de l’affinage des résultats de recherche ; etc.
Ces compléments d’informations sont encore et toujours bénéfiques à tous, pas uniquement aux personnes souffrant d’une déficience particulière.
Elles ont aussi l’avantage d’optimiser le référencement de la page Web.
Environnement des points géolocalisés
Ne mettre à disposition que les informations présentes dans la tooltip d’un point marqué n’est pas toujours suffisant.
En fonction du contexte de consultation et de ce que l’utilisateur recherche, l’environnement du point géolocalisé peut être une information essentielle à l’appréhension de l’information.
Il peut être important de savoir qu'un point géolocalisé se situe à proximité de tel ou tel lieu (rue, monument, etc.).
Ces informations sont peut-être primordiales et leur absence susceptible de rendre le contenu de l’infobulle inexploitable.
Une pratique efficace peut consister à systématiquement proposer en parallèle de la carte, un calcul d’itinéraire ainsi qu’une description des distances à partir de lieux déterminés comme stratégiques.
Dans l’idéal, ces itinéraires textuels doivent comporter un maximum d'informations sur les transports en commun et les points de repères pour un déplacement motorisé ou piéton.
L’exemple présenté sur le site votre-hotel.com
met intelligemment cela en pratique.
Ce travail de rédaction et de mise en œuvre d’alternatives "enrichies" est relativement délicat et le périmètre d’intervention est difficile à délimiter.
Où s’arrêter dans les explications et le complément d’informations à apporter ?
C’est un traitement au cas par cas, cela dépend des enjeux et des objectifs liés à la carte et à son contenu.
Ici, pour améliorer l’accessibilité de façon efficiente, bonne appréciation, compromis et arbitrage sont de mises.
Couleurs
Les fonds de carte fournis initialement par l’API Google Maps peuvent poser des problèmes liés à la perception des couleurs.
La couleur des indications textuelles (noms de rue, etc.) n’est parfois pas suffisamment contrastée avec les couleurs du fond de la carte.
Personnalisation des fonds de carte
La marge de manœuvre laissée par l’API et la liberté laissée en termes de personnalisation des fonds de carte permet de palier à ces problèmes de différences de contraste de couleur.
La solution technique envisageable est de superposer, sur la carte originale, sa propre composition.
Superposer une carte à Google Maps avec génération préalable de tuiles
.
Cette carte personnalisée doit évidemment présenter des ratios suffisants entre les différences de contrastes de couleurs des informations de premier plan et d’arrière plan.
4,5 étant la valeur attendue pour le niveau AA en petite taille de police selon les recommandations WCAG 2.0.
Outil de vérification des contrastes de couleurs "Colour Contrast Analyser"
.
Au moment de la conception de la nouvelle carte, il pourrait être intéressant de s’attacher à rendre sa consultation plus confortable.
Ainsi, en plus du respect des contrastes de couleurs, il peut-être judicieux :
- D’orienter correctement les textes en évitant de les présenter de manière verticale ou diagonale ;
- De proposer des textes de taille importantes ;
- D’épurer au maximum les informations présentes sur la carte pour n’y laisser que celles primordiales à sa consultation et à la compréhension du contenu ; etc.
Options et paramétrages
La carte présentée sur le site handimap.org
propose une option intéressante.
Elle laisse à l’utilisateur la possibilité de jouer sur la transparence donc sur la luminosité de la carte.
Cela peut s’avérer être, pour certains usagers, une option intéressante pour leur confort de consultation.
Bilan et perspectives
Implication de tous les acteurs
La mise en accessibilité d’un service de cartographie en ligne comme Google Maps nécessite que tous les intervenants du projet s’y intéressent et l’inclus dans leur processus de travail.
Cette remarque est bien souvent valable pour toute démarche de mise en accessibilité d’un contenu ou d’un service :
- Composant JavaScript riche ;
- Vidéo ;
- Document bureautique ; etc.
Tous les acteurs de la réalisation d’un projet Web sont impactés par cette question de l’accessibilité ; des concepteurs aux contributeurs.
Les décideurs, les AMOA - AMOE et les chefs de projet doivent faire part de leurs exigences au sein de leurs cahiers des charges et de leurs spécifications fonctionnelles et techniques.
Exemples d’exigences qu’il est légitimement possible d’exprimer dans un livrable :
- Il sera possible d’apporter des informations et des explications complètes quant à l’utilisation de la carte et de ses fonctionnalités ;
- Les interactions avec la carte devront pouvoir s’effectuer avec le clavier ;
- Les boutons de contrôles devront être externalisés, graphiquement personnalisés et rendus plus explicites ;
- En cas de non support de JavaScript, une image statique viendra en remplacement de la carte interactive ;
- Des alternatives textuelles aux points géolocalisés devront alimentées dynamiquement les résultats de recherche ;
- Les fonds de carte seront retravaillés afin de répondre aux exigences en termes de respect des différences de contraste de couleurs de premier et d’arrière plan ; etc.
Autres maillons de la chaîne impactés : les designers et concepteurs d’interface.
Ces derniers doivent penser à faire figurer les éléments essentiels à l’accessibilité du service au moment de la conception des Zonings, Wireframes, prototypes et autres maquettes graphiques :
- Emplacement pour les alternatives textuelles ;
- Design particulier des boutons d’actions ;
- Contrôles de la carte externalisés ; etc.
Les développeurs ont comme responsabilité la mise en œuvre des patchs et autres correctifs techniques.
Les contributeurs ont à charge de rédiger les explications concernant la carte et ses fonctions ainsi que les alternatives textuelles enrichies des points géolocalisés.
Pour résumé, l’accessibilité doit être pensée en amont et suivie tout au long de la conception de la fonctionnalité.
C’est ainsi que sa mise en œuvre sera efficace, transparente et la plus "rentable".
Vecteur de qualité
Comme bien souvent, se pencher sur l’accessibilité est gage d’amélioration de la qualité générale d’une fonctionnalité.
Il y a de nombreux recoupements et similitudes entres certaines recommandations en termes d’accessibilité et certaines bonnes pratiques Web.
De nombreux domaines de la qualité Web comme l’ergonomie, l’expérience utilisateur, le référencement ou encore les performances sont intimement liés à des exigences inhérentes à l’accessibilité.
Cela a été démontré tout au long de cette étude :
- Rendre utilisable au clavier les boutons de contrôle de la carte favorise le confort d’utilisation donc l’ergonomie du service ;
- Proposer des boutons d’action clairs et explicites favorise la prise en main et la compréhension des interactions possibles avec l’outil ;
- Apporter des informations quant aux objectifs de la carte et fournir des alternatives textuelles permet d’optimiser le référencement naturel des pages, cela peut aussi être bienfaisant pour les performances du service ; etc.
Amélioration à la source
Il pourrait être stratégiquement judicieux pour Google de réfléchir et de travailler à l’amélioration de l’accessibilité de leur solution de Webmapping.
Ainsi, c’est potentiellement plusieurs millions de nouveaux usagers qui pourraient bénéficier de leur outil.
Cela aurait comme impact positif de creuser encore davantage le fossé entre leur produit et celui des concurrents (voir : "Autres services de Webmapping").
Ce qui pourrait notamment représenter pour la firme, un gain commercial non négligeable.
Concrètement, il faudrait que l’équipe technique en charge de la maintenance et de l’évolution du service se penche sur cette question de l’accessibilité.
En d’autres termes, qu’ils fassent en sorte que les problèmes évoqués tout au long de cette étude (et d’autres encore) soient originellement correctement implémentés.
À la vue des récentes démarches entreprises quant à l’amélioration de l’accessibilité de certains de leurs autres produits (Docs, Sites et Calendar), il y a fort à penser que leur service de cartographie bénéficiera, un jour ou l’autre, du même traitement.
La publication récente des différentes sources proposées ci-dessous témoignent du réel intérêt porté par Google en matière d’accessibilité :
- Enhanced accessibility in Docs, Sites and Calendar
; - Google Enhance Accessibility for Docs, Sites and Calendar For Visually Impaired
; - [Google] - Making Google Accessible
; - [Google Code] - Accessible-maps
.
Il est tout de même utopique de penser que du jour au lendemain leur service de cartographie ne présentera plus aucun problème d’accessibilité mais il apparaît par contre plus réaliste que des améliorations soit apportées ponctuellement.
Autres services de Webmapping
Voici un recensement des principaux services gratuits de cartographie en ligne :
- Bing Cartes
; - Mappy
; - OpenLayers
; - Geoportail
; - ViaMichelin
; - 1bis
; - OpenStreetMap
; - Map24
; - Yahoo! Maps
.
Toutes ces solutions proposent quasiment les mêmes fonctionnalités : des plans, des itinéraires, des vues satellites, des informations sur le trafic ou sur la météo.
Dans le cadre de cette étude, l’évaluation de l’accessibilité des solutions exposées n’a pas été réalisée en profondeur.
On peut tout de même considérer, que pour l’ensemble des produits évoqués, on retrouve sensiblement les mêmes écueils décelés lors de cette étude de l’accessibilité de Google Maps :
- Navigation par tabulation défaillante ;
- Dépendance à JavaScript ;
- Absence d’alternatives textuelles ;
- Problèmes liés aux contrastes de couleurs ; etc.
Ressources
Présentation de Google Maps
Navigation au clavier
- [Communauté des développeurs d’Opéra] - Keyboard-accessible Google Maps
; - [Learning the World] - Enhanced Keyboard-accessible Google Maps
.
Personnalisation des contrôles
Alternatives et JavaScript
Personnalisation des fonds de carte
Autres services de Webmapping
[memoclic] - 10 services de cartographie en ligne ![]()
À propos de cette étude
Cette étude a été réalisé entre les mois de mai et septembre 2011 dans le cadre de la formation longue "Expert accessibilité" dispensée par la société "Temesis"
(promo 2011).
Elle a été réalisé par Johan Ramon et publié en novembre 2011.
Elle est mise à disposition selon le contrat "Creative Commons BY NC SA
".
Échanger sur les réseaux sociaux :