Des lecteurs d'écran pour tester votre site

Sophie Schuermans le 10/02/2014

Un lecteur d'écran est un logiciel utilisé par les personnes aveugles et malvoyantes. Il donne accès au contenu de l'écran en lisant le texte à voix haute au moyen d'un synthétiseur vocal, ou en l'affichant sur une plage braille.

Il peut être très intéressant de tester votre site web avec un lecteur d'écran parce que ce test peut faire apparaître des problèmes d'accessibilité difficiles à détecter d'une autre manière.

Si votre site utilise ARIA, il est indispensable de le tester avec un lecteur d'écran.

Il n'existe pas de statistiques concernant l'utilisation des lecteurs d'écran en Belgique. Il est donc difficile de déterminer avec quel(s) lecteur(s) d'écran il faut réaliser les tests.

Le lecteur d'écran est un logiciel qui lit un texte à l'écran. Cela paraît simple, mais cela ne l'est pas. Une page web est constituée de texte réparti en plusieurs colonnes et qui contient des images, des liens, des formulaires et éventuelement du contenu animé. Cet article décrit comment les lecteurs d'écrans arrivent tant bien que mal à lire l'information (EN).

Pour quelqu'un qui ne l'utilise pas au jour le jour, un lecteur d'écran est un logiciel assez complexe. Il est donc recommandé de prendre un peu de temps pour lire le manuel d'utilisation. Sinon vous risqueriez de conclure, peut-être à tort, que votre site est inutilisable avec un lecteur d'écran. L'article How to use NVDA and Firefox to test your web pages for accessibility peut être très utile pour démarrer. Il donne une bonne introduction à la manière d'utiliser un lecteur d'écran pour faire des tests, même si vous utilisez un autre lecteur d'écran que NVDA.

Conseils pour faire un test réaliste

Les personnes aveugles n'utilisent pas de souris et font tout en utilisant des raccourcis clavier. Pour faire un test correct, n'utilisez pas la souris en même temps que le lecteur d'écran.

Le lecteur d'écran lit tout ce qui se trouve à l'écran, dans un ordre bien précis, de manière linéaire. Un gros problème pour les personnes aveugles est de ne pas avoir de vue d'ensemble de l'écran. Un utilisateur de lecteur d'écran ne sait pas ce qu'il va rencontrer plus loin sur la page et n'est pas toujours informé de modifications dynamiques dans la page. C'est difficile à intégrer pour quelqu'un qui utilise un lecteur d'écran mais qui voit très bien la page web affichée. Pour faire un test réaliste il faudrait donc non seulement débrancher la souris, mais également éteindre l'écran. Il est clair que cela demande un peu d'entrainement.

Lecteur d'écran pour Windows

NVDA

Non Visual Desktop Access (NVDA) est un lecteur d'écran gratuit et open source. Une donation est toujours appréciée. Lors de l'installation vous pouvez choisir une version portable, qui permet de démarrer NVDA à partir d'une clé USB ou d'un répertoire sur votre disque dur sans rien devoir installer.

La voix francophone qui est fournie de manière standard n'est pas de très bonne qualité. Pour un prix raisonnable vous pouvez acheter un paquet de voix de qualité parmi lesquelles vous trouverez des voix francophones.

Microsoft Speech Platform est une autre option. Ces voix sont gratuites. Il faut d'abord installer le synthétiseur Microsoft Speech Platform - Runtime (Version 11), x86 . Attention, il faut installer la version x86 même si votre système est en 64-bit. Ensuite vous installez la voix que vous souhaitez utiliser à partir de la page Microsoft Speech Platform - Runtime Languages (Version 11). Choisissez les fichiers dont le nom contient TTS et non ceux qui contiennent SR. Par exemple pour la voix française Hortense il faut installer le fichier MSSpeech_TTS_fr-FR_Hortense.msi. Après avoir installé les voix, redémarrez votre ordinateur.

Dans NVDA vous devez indiquer quelles voix vous voulez utiliser. Sélectionnez d'abord un synthétiseur : appuyez sur insert+n, choisissez Préférences, puis Synthétiseur. Choisissez 'Microsoft Speech Platform' dans la liste. Si vous avez installé plusieurs voix, choisissez-en une en faisant Insert+n, préférences, paramètres vocaux.

Window Eyes

Window Eyes est un lecteur d'écran commercial que vous pouvez utiliser gratuitement si vous disposez d'une licence pour Office 2010 ou une version ultérieure.

JAWS

JAWS est un lecteur d'écran commercial qu'il est possible d'utiliser pendant 40 minutes dans sa version démo. Il faut ensuite redémarrer l'ordinateur pour pouvoir continuer à l'utiliser. Téléchargez JAWS en français. La version la plus récente est la 16. Choisissez une version 32 ou 64 bit en fonction de votre système d'exploitation.

Notez qu'il y a beaucoup d'utilisateurs de JAWS qui n'utilisent pas la version la plus récente car les mises à jour sont payantes. Pour faire un test réaliste il faudrait utiliser par exemple l'avant dernière version.

Il existe des voix de très bonne qualité. Il est possible de télécharger gratuitement des voix supplémentaires. Allez à Aides, Resources web, Téléchargement des voix Realspeak solo direct. Ces voix ne fonctionneront que dans JAWS.

Il existe un tutoriel pour apprendre à naviguer avec JAWS et WebAIM a publié un article Using JAWS to Evaluate Web Accessibility.

Supernova

On ne parle pratiquement jamais de ce logiciel dans les articles consacrés à l'accessibilité numérique et il n'est même pas mentionné dans le Screen Reader User Survey #5 de WebAIM. Toutefois ce lecteur d'écran commercial est encore largement utilisé en Belgique. Supernova ne gère pas bien les changements dynamiques de la page. Si vous testez avec Supernova, vous devez être conscient de cette lacune .

Lecteur d'écran pour Mac

Les utilisateurs de Mac n'ont pas besoin d'installer un lecteur d'écran. Depuis l'arrivée du système d'exploitation Lion le lecteur d'écran VoiceOver est intégré. Il suffit d'appuyer sur command+F5 et l'ordinateur commence à parler. La langue par défaut est l'anglais mais vous pouvez activer une autre langue dans les paramètres de VoiceOver. Lisez plus sur VoiceOver, le lecteur d'écran de Apple.

Smartphones et tablettes

Sur les appareils avec un écran tactile, le lecteur d'écran fait plus que lire le texte. Il fournit également une aide à la navigation. C'est donc un autre manière de travailler spécifique aux tablettes et smartphones. Consultez l'article La navigation avec un dispositif mobile pour les personnes handicapées à ce sujet.

Réagissez

Accessibilité du nouveau Vimeo

Sophie Schuermans le 03/02/2014

Vimeo a récemment annoncé le lancement de son nouveau lecteur multimédia. Ce nouveau lecteur n'utilise plus Flash mais HTML5 et il serait accessible. L'ancien lecteur ne l'était pas du tout et nous avions déconseillé de l'utiliser tel quel. Nous avons fait des tests pour voir si le nouveau lecteur offre une solution suffisamment accessible.

Flash encore très présent

Notre but était de tester la nouvelle version HTML5 du lecteur. Vimeo dit que le lecteur HTML5 est utilisé partout où c'est possible. Mais le lecteur Flash est encore utilisé dans certains navigateurs récents: les versions de Internet Explorer antérieures à IE11, Firefox pour Mac et Opera.

Certains types de fichier vont toujours être présentés dans la version Flash du lecteur. Dès qu'une vidéo est sous-titrée, c'est également le lecteur Flash qui est utilisé dans Firefox.

C'est un problème car la version Flash du lecteur n'est pas accessible du tout:

  • Le lecteur Flash n'est pas correctement utilisable au Clavier dans IE car les boutons de contrôle disparaissent.
  • Les boutons du lecteur Flash ne sont pas nommés et sont lus 'non étiqueté 1 bouton, 'non étiqueté 2 bouton', etc... jusqu'à 14.

Navigation au clavier

Dans le lecteur HTML5 de Vimeo, les boutons de contrôle peuvent être utilisés au clavier mais pas toujours de manière optimale. Le principal problème rencontré est la disparition des boutons de contrôle après quelques secondes.

En utilisant TAB, on parcourt d'abord le titre et infos sur la vidéo, puis les boutons 'Play', 'volume, 'CC', 'Full screen' et 'Vimeo', pour terminer avec les boutons 'J'aime', 'regarder plus tard' et 'Partager'.

ordre de tabulation dans Vimeo

Tant que l'on ne démarre pas la vidéo on peut naviguer dans le lecteur sans problème au moyen du clavier. Mais à partir du moment où on démarre la vidéo, les boutons de contrôle disparaissent rapidement. Le prochain tab amène alors au prochain lien dans la page après le lecteur vidéo. Si l'on revient en arrière (shift+tab), le comportement varie d'un navigateur à l'autre. Dans Chrome, Firefox et IE les boutons réapparaissent dès que le tab rencontre un bouton du lecteur. On peut alors les parcourir en sens inverse pour arriver où l'on veut. Il semble même qu'après cela ils restent visibles jusqu'à la fin. Mais dans Safari, il n'est pas possible de déplacer à nouveau le focus à l'intérieur du lecteur en tabulant en arrière.

C'est également dommage que le focus ne soit presque pas visible sur le bouton 'Play' dans Firefox. Il serait utile d'accentuer le focus (en copiant ce que l'on fait déjà pour hover).

Navigation au clavier, avec lecteur d'écran

Les boutons de contrôle du nouveau lecteur HTML5 sont bien nommés. Lorsqu'ils sont parcourus avec un lecteur d'écran on rencontre successivement les boutons 'like', 'add to watch later', 'share', 'play', 'volume', HD, 'Full screen'.

C'est dommage que le bouton Play arrive en quatrième position. Lors de la tabulation il se trouve en premier. La différence est causée par l'utilisation de tabindex. Les boutons ne sont pas dans l'ordre logique dans le code source et les attributs tabindex sont utilisés pour corriger l'ordre de tabulation. Un utilisateur de lecteur d'écran qui parcourt la page de manière linéaire (flèches haute et bas) ne bénéficie pas de cette adaptation. Ce serait mieux de mettre les boutons dans un ordre logique dans le code source.

Un problème plus sérieux est la disparition des boutons de contrôle. Après quelques secondes les boutons disparaissent et il n'est pas possible de les retrouver. Ils sont cachés de manière à n'être vus par personne, même pas les lecteurs d'écran. Une solution pourrait être de les cacher 'visuellement' de manière à ce qu'ils restent visibles par les lecteurs d'écran.

Sous-titrage

Il est possible d'ajouter des sous-titres. Les formats de sous-titres supportés sont SRT, WebVTT, DFXP/TTML, SCC, et SAMI.

Lors de l'ajout de sous-titres on peut indiquer s'il s'agit de sous-titres pour personnes sourdes et malentendantes (Captions) ou de simples sous-titres (subtitles).

spécification de la langue et du type de sous-titres dans Viméo

Lorsqu'une vidéo est pourvue de sous-titres, un bouton 'CC' apparaît automatiquement dans le lecteur vidéo. Il affiche un menu déroulant qui propose les différents sous-titrages disponibles. Les sous-titres pour sourds et malentendants sont identifiés au moyen de CC dans la liste .

menu de sélection de sous-titres, 2 choix: 'None' et 'Nederlands CC'

Vimeo ne propose pas de sous-titrage automatique ni d'outil pour créer des sous-titres. Il faut créer les sous-titres en utilisant un des nombreux outils disponibles.

Conclusion

La nouvelle version HTML5 du lecteur Vimeo présente plusieurs améliorations par rapport à l'ancienne version en Flash

  • Possibilité d'ajouter des sous-titres
  • Possibilité de naviguer au clavier
  • Boutons de contrôle nommés

Malgré toutes ces améliorations le lecteur vidéo n'est pas encore tout à fait accessible. Nous recommandons de ne pas intégrer des vidéos uniquement au moyen du code d'intégration proposé par Vimeo car :

  • Il y a encore plusieurs environnements dans lesquels c'est la version Flash (inaccessible au clavier et avec lecteur d'écran) qui sera utilisée.
  • La disparition des boutons de contrôle dans le lecteur HTML5 est un problème pour les utilisateurs de lecteur d'écran.

Si vous voulez héberger vos vidéos chez Vimeo et les proposer dans un format accessible, il faut compenser ces problèmes. Pour cela, vous pouvez utiliser Vimeo, et ajouter des boutons de contrôle externes en utilisant l'API Javascript, ou encapsuler le lecteur vidéo dans un autre lecteur vidéo accessible, comme celui de Nomensa, pour les présenter sur votre site.

Réagissez

Accessibilité des applications bancaires

Sophie Schuermans le 21/01/2014

Est-il possible en Belgique en tant que personne malvoyante ou aveugle de gérer un compte bancaire en ligne de manière autonome? Nous avons examiné les applications bancaires en ligne de 4 grandes banques belges: Belfius, BNP Paribas, ING et KBC.

logo Belfuis, BNP Paribas, ING et KBC

Il est rapidement clair qu'aucun des sites web n'a été conçu dans le but d'être accessible à tous. Il y a de nombreuses remarques à faire sur chacun des sites. Mais sur certains des sites ces remarques sont moins bloquantes que sur d'autres.

Pour pouvoir faire des opérations en ligne il faut d'abord pouvoir se connecter. Nous examinons d'abord le processus d'authentification, puis les applications elles-mêmes.

L'authentification avec lecteur de carte

Pour que l'authentification soit possible pour tous il faut que le lecteur de carte le soit également.

5 petits lecteurs de cartes et un grand

Le système le plus répandu pour s'authentifier était, jusqu'à récemment, un lecteur de carte avec touches 'm1' et 'm2', un clavier numérique et un petit écran. Les personnes aveugles ou malvoyantes ne peuvent pas lire le code qui y est affiché. Il existe de ce lecteur de carte une version accessible aux personnes aveugles et malvoyantes: un lecteur de carte 'parlant'. Les touches sont également plus grandes et donc plus lisibles.

Ce système accessible est proposé chez Belfius, BNP Paribas, et KBC mais plus chez ING.

ING utilise un lecteur de carte différent. Il n'existe pas à notre connaissance de version accessible de ce lecteur de carte. Les personnes malvoyantes ne peuvent donc pas se connecter à l'application en ligne de ING.

KBC a introduit en parallèle un nouveau lecteur de carte qui n'est pas utilisable par les personnes aveugles et malvoyantes et qui posera également problème aux personnes ayant des difficultés motrices : c'est un scanner qu'il faut maintenir immobile contre l'écran pour scanner un code barre clignotant.

fenêtre de login KBC avec deux options de lecteur de carte et code barre à scanner

A ce stade de notre évaluation, ING est donc éliminé puisqu'une personne malvoyante ne peut se connecter à leur application en ligne.

Les 3 autres banques mettent à disposition un lecteur de carte parlant indispensable. Il reste à voir si les applications des trois banques restantes sont accessibles.

Faire des opérations bancaires

Chez Belfius on rencontre des problèmes bloquants. Chez KBC et BNP Paribas, il y a des problèmes également mais les services en ligne peuvent devenir utilisables par des personnes aveugles et malvoyantes, moyennant apprentissage.

Commençons par Belfius. Le bouton pour se connecter est facile à trouver sur la page d'accueil, la connexion est possible, mais les problèmes commencent lorsque l'on arrive dans l'application. Le problème principal réside dans la mauvaise implémentation des formulaires. De faux éléments de formulaires sont utilisés. On a par exemple des boutons radios (visuellement) ou des listes déroulantes qui sont en réalité des liens. De nombreux champs de formulaire ne sont pas reliés à leur label. Une personne aveugle ne sait donc pas à quoi correspondent ces champs et ne peut pas les rempli correctement.

Ce qui est vraiment dommage, c'est que la version précédente de l'application Belfius était accessible, ce qui a du attirer pas mal de clients aveugles et malvoyants. L'accessibilité a manifestement été oubliée lors de la refonte.

Chez KBC, il faut être persévérant pour trouver le bouton qui permet d'accéder à l'écran de connexion. Visuellement il est facile à trouver car il se trouve en haut à droite. Mais dans le code source, il est précédé d'un très long menu et se trouve à la ligne 323. Un visiteur qui n'utilise que le clavier doit enfoncer 200 fois la touche TAB pour y arriver. Les titres de pages ne sont pas significatifs (par exemple 'KBC-Online dy540A-dy54001TransferOtherAccountScreen'). Dans les explications qui accompagnent l'authentification, les images qui représentent les boutons 'm1' et 'OK' ont des attributs alt vides, ce qui rend l'explication peu utile.

Chez BNP Paribas, on rencontre également des attributs alt qui ne sont pas significatifs et certains champs mal labellisés. Cela rend l'utilisation du site plus compliquée, mais néanmoins possible pour un utilisateur averti.

Chez ING, même s'il était possible de se connecter, l'utilisateur aveugle se retrouverait dans l'impossibilité de faire des opérations. La procédure pour signer un virement demande de recopier une série de chiffres qui sont présentés sous forme d'image, sans alternative textuelle.

Conclusion

Seules deux des 4 banques examinées ont des applications en ligne utilisables par les personnes ayant un handicap visuel. Celles-ci se voient donc obligées de choisir leur banque en fonction de critères purement techniques, et non commerciaux.

Que devraient faire les banques?

  • Avoir une démarche inclusive et penser à tous leurs clients potentiels lorsqu'elles choisissent des mécanismes d'authentification et le lecteur de carte.
  • Exiger de leurs prestataires web que les services en ligne respectent les directives AnySurfer.
  • Ne pas oublier l'accessibilité lors de la refonte de leur site ou de leurs applications.

Quelques remarques pour terminer

  • Cette analyse a été faite en décembre 2013. La situation décrite ci-dessus peut avoir changé entre-temps.
  • Nous nous sommes limités aux sites web. Ces banques ont également des applications pour smartphones et tablettes. Ce serait intéressant d'en analyser l'accessibilité car les personnes handicapées peuvent aussi utiliser les applications mobiles à condition qu'elles soient accessibles.
  • Les banques peuvent également aider les personnes aveugles et malvoyantes autrement, par exemple en proposant des extraits en braille ou imprimés en grand, des automates 'parlants', un personnel serviable etc. Ce sont également des critères qui entrent en compte dans le choix d'une banque.
  • AnySurfer se ferait un plaisir de travailler avec les banques à améliorer l'accessibilité des leurs applications en ligne: qu'elles n'hésitent pas à nous contacter.
  • Merci beaucoup au SBPV et aux testeurs aveugles et malvoyants qui nous ont aidé à effectuer cette analyse. .
2 réactions

Des liens sur la même page qui fonctionnent pour tout le monde

Sophie Schuermans le 07/01/2014

Mise à jour le 22 septembre 2016: le problème est résolu dans la plupart des navigateurs mais reste d'actualité dans IE11 et Edge.

J'ai découvert récemment que les liens sur la même page ne fonctionnent pas dans tous les navigateurs. Je parle bien des liens du type <a href="#contenu">Aller au contenu</a> que l'on utilise par exemple pour construire un lien d'évitement.

Lien d'évitement 'aller au contenu' sur une page du site anysurfer.be

Les liens d'évitement sont utiles aux personnes qui naviguent sans souris car ils permettent d'arriver directement au contenu. Sans lien d'évitement, il faut passer d'abord par tous les liens de la navigation en utilisant la touche TAB du clavier, avant de pouvoir atteindre les liens du contenu.

Les liens sur la même page sont également utilisés pour créer une table des matières sur une page un peu longue (par exemple un tutoriel sur l'accessibilité des documents Word), ou dans des mini-sites où tout le contenu se trouve sur une seule longue page.

C'est pour les utilisateurs du clavier (sans souris) que ce type de liens est le plus utile. Malheureusement c'est aussi pour ces mêmes utilisateurs que ces liens ne fonctionnent pas. Heureusement la solution n'est pas très compliquée.

Exemples

Dans cet exemple il y a deux liens vers des paragraphes qui se trouvent plus bas.

<p><a href="#suite1">Aller a la suite de l'exemple (1)</a></p>
<p><a href="#suite2">Aller a la suite de l'exemple (2)</a></p>

Lorsque l'on utilise ces liens, que ce soit avec le clavier ou la souris, il faut qu'il se passe deux choses: un défilement de la page pour que le paragraphe en question soit visible et un déplacement du focus vers ce paragraphe.

Si vous utilisez Firefox, les deux liens se comportent de la même manière. Si vous utilisez un autre navigateur, le premier lien ne se comporte pas comme prévu.

Pour voir la différence, dans la page exemple, utilisez le TAB pour atteindre le lien 'Aller à la suite de l'exemple (1)' puis faites 'ENTER'. La page défile pour afficher le paragraphe 'Exemple (suite 1)'. Ensuite faites de nouveau TAB pour atteindre le lien 'lien' qui se trouve dans ce paragraphe. Dans Firefox vous arrivez directement sur le lien 'lien'. Dans les autres navigateurs vous remontez au lien 'Aller à la suite de l'exemple (2)' qui se trouve ci-dessus.

Le lien 'Aller à la suite de l'exemple (2)' fait défiler la page pour afficher le paragraphe 'Exemple (suite 2)', et déplace également le focus au début de ce paragraphe. Le prochain TAB vous amènera donc vers les premier lien de ce paragraphe ('autre lien'). C'est le comportement attendu.

Code

Quelle est la différence entre les deux liens? Voici le code du premier lien, qui ne fonctionne pas bien partout:

<a href="#suite">Aller a la suite de l'exemple (1)</a>

La destination du lien est un titre de niveau 2 avec id="suite":

<h2 id="suite" >Exemple (suite 1)</h2>

Qu'est-ce qu'il a fallu faire pour que le deuxième lien se comporte comme voulu?

  • Ajouter un attribut tabindex="-1" sur l'élément qui sert de destination au lien:

    <h2 id="suite" tabindex="-1" >Exemple (suite 2)</h2>

    La valeur "-1" de l'attribut tabindex fait en sorte que l'élément (ici h2) n'entre pas dans l'ordre de tabulation, mais par contre il est possible d'y déplacer le focus.

    L'ajout de l'attribut tabindex à lui seul suffit dans Chrome, Opera, Internet Explorer et Safari (pour Mac), en tous cas leurs versions récentes.

  • Inclure les bibliothèques Jquery, ainsi qu'un script qui utilise la fonction focus():

    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
    
    <script>
      $(document).ready(function() {
        // ajouter un 'click handler' pour tous les liens
        // dont la cible est sur la meme page (href="#...")		
        $("a[href^='#']").click(function() {
          // trouver l'attribut href du lien,
          // en supprimer le premier caractere (#)
          // ce qui donne la valeur de l'attribut id de la cible
          $("#"+$(this).attr("href").slice(1)+"")
            // donner le focus a l'element avec cet id (pour les navigateurs qui ne le font pas)
            .focus();
        });
      });
    </script>

    L'addition de Javascript est nécessaire pour que cela fonctionne dans Safari sur Windows.

Voir l' article très complet de Terril Thomson sur le skip link (en anglais) dont vient cette technique. Il y décrit également des techniques pour accentuer le focus et la transition du focus.

Note sur les lecteurs d'écran

  • Avec JAWS et NVDA Les liens sur la même page fonctionnent correctement de manière standard : le focus se déplace vers la destination du lien. La lecture reprend à cet endroit et si l'on utilise le TAB, il n'y a pas de problème non plus.
  • Avec Voiceover le même problème se pose pour le focus du clavier, et la solution proposée fonctionne également.

Conclusion

Les liens sur la même page ne fonctionnent pas toujours correctement au clavier. Pour qu'ils fonctionnent toujours il faut utiliser l'attribut tabindex="-1" sur la destination du lien, et ajouter un petit peu de Javascript. C'est très important pour ceux qui naviguent sans souris. Pensez-y donc lorsque vous créez une table des matières ou des liens d'évitement.

- 3 réactions

La navigation avec un dispositif mobile pour les personnes handicapées

Pierre Jourdain le 31/10/2013

Nous sommes de plus en plus souvent invités à tester des applications qui tournent sur une plateforme mobile. Le premier aspect à prendre en compte est le degré d'accessibilité des appareils et de leur système d'exploitation. Dans un prochain article, nous parlerons de l'accessibilité des applications et de ce qu'un développeur doit prendre en compte. Nous nous limiterons dans cet article aux plate-formes Android et iOS.

Portables et ordinateurs de bureau

Les ordinateurs exécutant le système d'exploitation Windows (jusqu'à la version 7) sont utilisables par les personnes handicapées grâce à une gamme d'outils matériels et logiciels. Ces aides techniques doivent être acquises séparément, ce qui suppose parfois un coût supplémentaire important.

Apple a pris les choses en mains en équipant son système d'exploitation de nombreuses fonctionnalités d'accessibilité sans aucun coût supplémentaire pour l'utilisateur. Le fait que Apple développe le système d'exploitation et les aides techniques, garantit la cohérence globale. L'avantage de cette approche est que les aides techniques évoluent de pair avec le système d'exploitation. Le revers de la médaille est le manque de concurrence en ce qui concerne les aides techniques et que l'utilisateur ne peut pas configurer le système via programmation.

Ecrans tactiles

Les écrans tactiles modifient fortement la façon de travailler et cela a des conséquences en ce qui concerne l'accessibilité. Pour les personnes avec un handicap moteur, un écran tactile sera souvent plus facile à utiliser qu'un clavier et une souris traditionnels. Initialement, les personnes aveugles étaient assez inquiètes au sujet des écrans tactiles. Heureusement les fabricants et les fournisseurs ont prévu des solutions. Le lecteur d'écran pour Android: Talkback et celui pour iOS: VoiceOver. Des programmes de reconnaissance vocale comme Google Voice et Siri peuvent être utilisés par tout le monde, mais permettront aux personnes handicapées d'utiliser plus facilement et rapidement leur terminal.

Les personnes handicapées, vont comme tout le monde, de plus en plus visiter des sites web en utilisant des tablettes ou des smartphones équipés d'un écran tactile.

Accessibilité des tablettes et des téléphones

Les iPhone/iPad sont les plus accessibles pour les personnes souffrant de différents handicaps. En termes d'accessibilité, le système fermé de Apple constitue un avantage: il n'y a qu'un seul fabricant qui propose peu de terminaux différents: l'accessibilité est intégrée dans le système d'exploitation sans qu'il soit nécessaire d'installer des logiciels supplémentaires. Apple inclut de manière standard de nombreuses applications avec le système d'exploitation et celles-ci sont en général parfaitement accessibles.

Par contre, il est difficile de savoir si une app que vous souhaitez installer sera accessible ou non. La mise à jour d'une app est également risquée car il arrive que la nouvelle version soit moins accessible que l'ancienne. Et il est impossible de réinstaller la version précédente d'une app depuis l'appstore.

Chaque nouvelle version d'Android s'améliore en termes d'accessibilité et se rapproche de l'iPhone / iPad. Il y a cependant deux soucis majeurs si le téléphone n'est pas de la série Nexus: les fabricants ne permettent pas toujours d'actualiser le système d'exploitation à la dernière version. Jelly Bean est la version minimale dont doit être pourvu le terminal pour garantir l'accessibilité de celui-ci. De plus, de nombreux fabricants ajoutent une couche logicielle supplémentaire ou modifient certaines fonctions. Ces adaptations font que l'accessibilité de l'appareil sera moins prévisible pour les utilisateurs d'aides techniques, comme par exemple les lecteurs d'écrans.

La meilleure accessibilité sera offerte par les terminaux de la gamme Nexus car ils sont pratiquement les seuls à être complètement Android. Mais même avec ces appareils, toutes les applications fournies de manière standard ne sont pas accessibles (par exemple: l'agenda).

GARI (Global Accessibility Reporting Initiative) est une base de données consultable en ligne qui répertorie les fonctions d'accessibilité des smartphones et des tablettes. Elle permet de mieux choisir le terminal en fonction du handicap de l'utilisateur.

Conclusion

Un grand travail a été accompli pour rendre aussi facilement utilisables ces nouveaux terminaux par les personnes handicapées que le sont les ordinateurs classiques. Dans un prochain article, nous parlerons de ce qu'implique cette nouvelle façon de travailler pour les développeurs de sites web mobiles ou d'apps .

2 réactions