The purpose of the day is to get people talking, thinking and learning about digital (web, software, mobile, etc.) accessibility and users with different disabilities.

Nous voulons nous intéresser aujourd'hui au Service Public. A tous les niveaux (fédéral, régional, pouvoir locaux), le Service Public s'engage résolument dans la voie du numérique. C'est une excellente nouvelle car le monde numérique a le potentiel d'être plus accessible que le monde physique. Mais aujourd'hui il est loin de l'être.

Les différents niveaux de pouvoir en Belgique partagent notre vœu d'un service public plus accessible. Il n'y a aucun doute à ce sujet. Ils ont signé la convention ONU sur les droits des personnes handicapées et il existe au niveau fédéral une loi pour lutter contre les discriminations. Mais la mise en œuvre n'est pas efficace et ne produit que peu de résultats.

Un passé peu probant

Depuis 2003 le gouvernement wallon s'est engagé à rendre accessibles la majorité des sites web de la Région Wallonne, comme l'indique la déclaration d'accessibilité de presque tous ses sites. Mais à part les sites de l'AWIPH, cela fait quelques années qu'aucun site du service public wallon n'a plus été labellisé AnySurfer.

Le secteur touristique fait exception et se distingue par son attention pour l'accessibilité de ses sites web. Cela s'explique par le label '5 soleils' qui récompense les attractions touristiques de qualité et exige entre autres l'obtention du label AnySurfer.

Du côté de la Flandre, c'est en 2004 que le gouvernement a décidé que tous ses sites devraient être accessibles. Comme en Wallonie, l'accessibilité fait partie du cahier des charges des appels d'offres. Mais il ne semble pas y avoir de contrôle, de récompense ou de pénalité, quel que soit le résultat. Le projet Toeweb qui avait contribué, entre autres grâce à des formations, à améliorer de manière significative l'accessibilité des sites web flamands a été mis en veille.

Chaque année des dizaines des sites du service public fédéral sont audités à la demande de la Chancellerie du Premier Ministre. Après réception du rapport d'audit, qui est pourtant truffé d'explications, rares sont les sites pour lesquels des corrections sont faites en vue d'améliorer l'accessibilité. Ce n'est pas si étonnant car les rapports d'audit n'ont en général pas été demandés par les responsables des sites.

A Bruxelles trois ordonnances ont été votées en matière d’égalité de traitement et de promotion de la diversité au sein des entreprises privées et des institutions publiques régionales et locales. Elles semblent être respectées pour les nouveaux sites ayant trait à l'emploi. Plusieurs sites de la région Bruxelloise ont été labellisés les deux dernières années et des formations ont également été données à l'intention de fonctionnaires de la région.

Un futur encore incertain

Dans l'accord du gouvernement fédéral il y a deux phrases qui nous intéressent :

L’autorité étudiera les modalités lui permettant de favoriser, de concert avec les communautés et la société civile, l’inclusion numérique, tant sur le plan de l’accessibilité et de l’accès que sur le plan de l’utilisation des TIC dans la vie quotidienne.

Les sites web et les documents numériques seront au maximum accessibles à tous les usagers, en ce compris les personnes âgées, les daltoniens, les malvoyants et les personnes avec un handicap.

Nous pensions que cela se concrétiserait lors du lancement du plan Digital Belgium de monsieur le ministre De Croo. Ce plan d'action numérique définit une vision à long terme pour notre pays et la traduit en ambitions concrètes. Nous n'y avons pas trouvé un mot sur l'accessibilité.

Nous espérons que la proposition de loi sur l'accessibilité numérique se concrétisera. Presque tous les pays Européens ont une législation dans ce domaine. N'attendons pas que la directive Européenne nous y oblige.

En Wallonie l'Agence du Numérique a pour mission de définir et mettre en œuvre les politiques publiques wallonnes en matière de TIC, pour faire de la Wallonie un territoire d'excellence numérique. Sans accessibilité on ne pourra pas parler d'excellence.

La Flandre va investir 10 millions d'Euros dans les 3 prochaines années dans les services numériques. La nouvelle agence 'Informatie Vlaanderen' est chargée du projet.

To do

Que ce soit au niveau fédéral, en Flandres, en Wallonie ou à Bruxelles, l'accessibilité numérique ne fait pas encore partie de manière explicite de l'agenda numérique. Il faut absolument l'y inclure, sans quoi elle sera oubliée.

La législation ne suffit cependant pas pour créer des sites web et services accessibles. Voici quelques points clés pour aller vers un Service Public plus accessible:

1. Sensibiliser. Les règles d'accessibilité sont perçues comme des contraintes et se heurtent à beaucoup de résistance. Il faut sensibiliser à tous les niveaux de l'organisation pour faire comprendre l'importance de l'accessibilité et vaincre cette résistance.
2. Placer la responsabilité au bon endroit. Tout le monde a un rôle à jouer, mais il vaut mieux donner la responsabilité du côté technique, à ceux qui produisent les services, plutôt que dans des services liés au handicap où à l'égalité des chances.
3. Connaissances et expertise. Formez des collaborateurs pour qu'ils aient l'expertise nécessaire en accessibilité, ou engagez des personnes ayant cette expertise. Exigez que les prestataires externes aient un expertise suffisante en accessibilité.
4. Processus. Intégrez l'accessibilité à chaque étape des processus de production de contenu ou de services en ligne. C'est beaucoup plus efficace que de demander un audit quand tout est fini.
5. Outils. Choisissez des outils (CMS, plugins, langages de programmation) les plus accessibles possible ou investissez l'amélioration de leur accessibilité. Ré-utilisez un maximum de composants accessibles. Améliorez-les en continu .

Ils l'ont fait

Comme bon exemple, on peut citer le gouvernement canadien. Une personne aveugle avait déposé une plainte parce qu'elle ne pouvait pas postuler en ligne pour un emploi du Service Public. Le Canada a perdu le procès et s'est trouvé dans l'obligation de rendre ses sites web accessibles. En 15 mois le gouvernement canadien a formé 4000 développeurs et rendu accessibles 10 millions de pages web. Conseils:

• Get senior management buy-in either by carrot or stick.
• Choose the IT frameworks carefully
• Design for accessibility when the cement is wet
• Get the templates right
• Train your staff

En conclusion

Au ministre fédéral de l'Agenda Numérique Alexander De Croo,
à la ministre Flamande de l'intérieur et de l'égalité des chances Liesbeth Homans,
à la secrétaire d'état Bruxelloise pour l'egalité des chances, l'informatique et la transition numérique Bianca Debaets,
au ministre Wallon de l'innovation et du Numérique Jean-Claude Marcourt:

Pouvons nous travailler ensemble pour faire avancer l'accessibilité numérique?

Accessibilité du Service Public rédigé par Sophie Schuermans dans Default

]]> Thu, 21 May 2015 12:30:00 +0200 https://www.anysurfer.be/fr/blog/detail/accessibilite-du-service-public https://www.anysurfer.be/fr/blog/detail/le-defilement-infini?utm_source=feed&utm_medium=rss&utm_campaign=le-defilement-infini Le défilement infini ou Infinite scrolling est une technique qui consiste à charger automatiquement le contenu de la page lorsque l'utilisateur atteint le bas de celle-ci. C'est le cas, par exemple, de la ligne du temps du profil Facebook.

C'est une alternative à la traditionnelle pagination que l'on trouve, entre autres, dans le bas de la page des résultats de recherche de Google.

Le défilement infini présente des avantages, notamment sur un appareil mobile. Il permet d'économiser de l'espace sur l'écran et l'utilisateur peut, simplement en glissant son doigt sur l'écran, faire apparaître du contenu supplémentaire.

The advantage of not having to acquire and click “next page” keeps audiences engaged with the content and less focused on the mechanics of navigating to the next page.

Hoa Loranger Norman Nielsen Group

Cette technique présente malheureusement beaucoup d'inconvénients.

Accessibilité

• Cette technique est incompatible avec la présence d'un pied de page. L'apparition automatique de nouveau contenu repousse à chaque fois le pied de page vers le bas. Celui-ci ne sera donc jamais atteint. Le contenu ajouté dynamiquement doit donc être le dernier contenu de la page.
• C'est un comportement inattendu et non sollicité. C'est déroutant pour quelqu'un qui n'a pas de vue d'ensemble de l'écran. L'utilisateur doit toujours avoir le contrôle sur la page. Le nouveau contenu devrait donc être chargé lorsque l'utilisateur le demande. Ceci peut être facilement résolu en ajoutant un bouton "Charger plus de résultats".

Usability

Le déroulement infini peut être une option pour des sites où tout le contenu est de même niveau. C'est le cas, par exemple, des sites Facebook, Pinterest et Twitter. Pour les sites web applicatifs (recherche de produits, commandes en ligne, comparateurs de prix...), cette technique présente trop d'inconvénients.

Le déroulement infini:

• rend difficile la recherche dans une page.
• est désorientant. L'utilisateur ne voit pas où il se trouve. La barre de défilement ne représente pas correctement la longueur de la page.
• limite le contrôle de l'utilisateur. Il ne peut pas atteindre le bas de la page.
• crée une fatigue psychologique, l'utilisateur n'a pas de liste mentale de la page.
• rend la navigation difficile, l'utilisateur ne peut pas accéder directement à une page, ce qui, par contre, est possible avec la pagination.

Sources

• Infinite Scrolling Is Not for Every Website - Nielsen Norman Group
• Infinite Scrolling: Let's Get To The Bottom Of This - Smashing Magazine
• Infographic pro's and con's of infinite scrolling - webdesignerdepot

Conclusion

Ne l'utilisez pas pour les sites web orientés tâches. Pour ces cas, la pagination numérotée est plus adaptée. Si le contenu de votre site s'y prête, ajoutez plutôt un bouton "charger plus de messages" . Testez avec le clavier ainsi qu'avec un lecteur d'écran.

Le défilement infini rédigé par Nicole Reyes Guttmann dans Default

]]> Mon, 13 Apr 2015 11:46:00 +0200 https://www.anysurfer.be/fr/blog/detail/le-defilement-infini https://www.anysurfer.be/fr/blog/detail/be-hackathon-des-apps-pour-les-personnes-handicapees?utm_source=feed&utm_medium=rss&utm_campaign=be-hackathon-des-apps-pour-les-personnes-handicapees Plus de 70 étudiants ont participé au premier Be-hackathon qui a eu lieu les 26, 27 et 28 mars à l'initiative de Be.Wan dans les locaux du Wagon, au sein de l’espace de coworking co.station. Chaque équipe de quatre développeurs devait relever le même défi : développer en 36 heures une application pour mobile qui aiderait les personnes handicapées dans leur quotidien.

AnySurfer avait été invité à contribuer à la soirée de lancement du 18 mars. Après la présentation de l’organisation du week-end par Gilles Boon de Be.Wan, les représentants du Creth ont pris la parole pour expliquer comment les personnes handicapées utilisent les smartphones et tablettes dans leur quotidien. Vincent Collin a insisté sur l'importance de tester les applications avec plusieurs utilisateurs.

Notre collègue Bart De Clercq a fait un tour d'horizon des différentes options d'accessibilité disponibles sur iOS et Androïd. Nous avons vu que ces options permettent de faire énormément de choses. Par contre des applications en apparence assez simple ne sont pas accessibles si elles sont mal conçues. Bart a cité l'exemple de l'application d'Uber qui était accessible et beaucoup utilisée par des personnes aveugles mais dont le bouton principal est devenu inutilisable avec VoiceOver suite à une mise à jour de l'application.

Les développeurs ont donc une grande responsabilité lorsqu'ils développent des applications : Le design et la manière dont elle est codée sont déterminants pour son accessibilité. Bart a conclu en donnant quelques pistes pour développer des apps accessibles.

Après les présentations, nous avons eu l’occasion de rencontrer les participants du hackathon, très motivés. Des personnes handicapées étaient également présentes pour répondre aux questions, réagir aux idées des étudiants ou exprimer leurs propres besoins.

Le dimanche 28 mars le jury a sélectionné quatre applications. Bien qu'elle ne soient pas tout à fait fonctionnelles, ces applications laissent entrevoir un très beau potentiel. Mais nous n’avons pas eu l’occasion d'examiner leur accessibilité.

Première place : Metro

Cette application principalement destinée aux personnes aveugles ou malvoyantes. Le problème initial est qu’il est terriblement compliqué pour ces personnes d’utiliser les transports publics. Souvent, sur un même quai, plusieurs lignes sont desservies et aucun indicateur non visuel permet d’être tenu informé de quel métro arrive en station.

L’application résout le problème en annonçant à haute voix le numéro du métro, ainsi que sa destination, lors de son arrivée en station.

Elle se connecte aux API fournies par les sociétés de transports en commun (pour la démo, ce fût le réseau de métro Londonien)

Deuxième place : EasyVoice

Le contexte initial : un membre de l’équipe est papa d’un enfant souffrant d’un handicap lui rendant, entre autres, l’usage de la parole assez difficile. L’enfant utilise couramment une application sur tablette lui permettant d’énoncer des phrases préenregistrées. L’inconvénient majeur de cette solution est que l’enfant doit transporter une tablette – ce qui est loin d’être facile pour lui.

L’application fonctionne sur une smartwatch et ne nécessite aucune connexion à Internet. L’enfant peut donc utiliser cet outil à tout moment, directement sur son poignet.

Troisième place : Swipe

Cette application simplifie à l’extrême l’utilisation d’un téléphone. Elle est destinée aux personnes pour lesquelles l'utilisation d'un téléphone est trop compliquée, comme par exemple une personne atteinte de la maladie d'Alzheimer.

Swipe permet de créer des raccourcis aux fonctionnalités du téléphone via deux moyens :

• Dessiner une forme sur l’écran
• Approcher le téléphone d’un tag NFC : Le simple fait d’approcher le téléphone sur un tag lancera, par exemple, un appel vers un membre de la famille ou vers un service de secours.

Quatrième place : Pin It

Destinées aux personnes aveugles ou malvoyantes, l’application utilise également des étiquettes NFC. Elle fonctionne sur le principe du labelpen. L’idée est d’apposer des étiquettes NFC sur tous les objets du quotidien : brique de lait, médicaments, vêtements, etc. Ensuite, l’utilisateur posera son téléphone sur un objet étiqueté (un médicament, par exemple) et celui-ci dictera à haute-voix les informations.

Be-hackathon : des apps pour les personnes handicapées rédigé par Nicole Reyes Guttmann dans Default

]]> Fri, 03 Apr 2015 14:30:00 +0200 https://www.anysurfer.be/fr/blog/detail/be-hackathon-des-apps-pour-les-personnes-handicapees https://www.anysurfer.be/fr/blog/detail/laccessibilite-des-ibooks?utm_source=feed&utm_medium=rss&utm_campaign=laccessibilite-des-ibooks Les sites Web, mais également les documents numériques doivent être accessibles à tous. Les principes sont identiques pour tous les formats, mais les techniques à utiliser pour atteindre l'accessibilité varient selon le logiciel utilisé. Nos collègues de Blind d mobiel ont décrit ces techniques pour le logiciel iBooks Author, qui permet de créer des iBooks.

iBooks?

iBooks est l'interprétation d'Apple de la norme ePub pour les livres numériques. La première version de iBooks date d'avril 2010 et était pleinement conforme à la norme ePub. Lors du lancement de la deuxième version de iBooks en janvier 2012, Apple a ajouté quelques éléments au format des iBooks qui ne sont pas prévus par la norme ePub. Suite à cela, un iBook peut désormais contenir beaucoup plus d'éléments interactifs, mais ne répond plus à la norme ePub.

Pour ouvrir et lire un iBook, vous aurez besoin du logiciel "iBooks", qui est disponible pour:

• iOS (iPhone, iPad, iPod touch) : l'application fonctionne très bien avec les logiciels de synthèse vocale et d'agrandissement typiques de ces dispositifs.
• Mac OS X (pour Mac) : malheureusement, l'application n'est cette fois pas aussi accessible pour les utilisateurs de VoiceOver.

Comment créer un iBook accessible?

Le logiciel gratuit iBooks Author (disponible uniquement sur MAC) permet la création de livres électroniques iBooks. Via sa plate-forme de vente online, Apple vous permet de proposer vos livres électroniques à la vente. Il est également possible de les proposer sur votre propre site.

Durant le processus de création d'un livre iBooks, il faut tenir compte de certains points pour garantir que le résultat final sera accessible. Les techniques pour y parvenir sont décrites dans un document ADOD. (ADOD = Accessible Digital Office Documents). Les directives de AnySurfer s'appliquent aux sites web. Pour tous les autres documents électroniques, les manuels ADOD sont la référence. Le document (en anglais) Authoring Techniques for Accessible Office Documents: iBooks Author ver2 décrit les techniques a utiliser pour rendre un iBook accessible. Le document est également disponible en néerlandais (Technieken voor het produceren van Toegankelijke Office Documenten: iBooks Author v2).

Ce travail a été présenté lors du colloque Des livres numériques accessibles ! Une chance pour des bibliothèques accessibles à tous les publics qui s'est tenu à Paris les 22 et 23 août 2014. Les textes et les slides de la présentation sont disponibles sur le site de l’événement.

L'accessibilité des iBooks rédigé par Nicole Reyes Guttmann dans Default

]]> Thu, 04 Sep 2014 14:17:00 +0200 https://www.anysurfer.be/fr/blog/detail/laccessibilite-des-ibooks https://www.anysurfer.be/fr/blog/detail/lelement-placeholder-nest-pas-un-label?utm_source=feed&utm_medium=rss&utm_campaign=un-placeholder-nest-pas-un-label L'attribut placeholder est parfois utilisé à la place du label dans les formulaires. Un placeholder n'est pas une alternative à part entière pour un label. Un label visible est indispensable.

Un placeholder n'est pas un label rédigé par Nicole Reyes Guttmann dans Default

]]> Tue, 12 Aug 2014 11:57:00 +0200 https://www.anysurfer.be/fr/blog/detail/lelement-placeholder-nest-pas-un-label https://www.anysurfer.be/fr/blog/detail/jquery-ui-dialog?utm_source=feed&utm_medium=rss&utm_campaign=jquery-ui-dialog jQuery UI permet d'utiliser facilement des fenêtres de dialogue. Ce type de fenêtre peut contenir une notification avec ou sans boutons, un formulaire complet ou tout autre contenu.

Cette boite de dialogue est injectée dans le code source de la page et se superpose au reste de la page via CSS. Dans sa configuration par défaut, la fenêtre créée avec jQuery UI pose quelques problèmes d'accessibilité. Notamment pour les utilisateurs qui naviguent au clavier ou avec un lecteurs d'écran.

• Lors de l'ouverture de la fenêtre, celle-ci ne reçoit pas le focus.
• En tabulant, le focus est visible dans l'arrière-plan mais ne permet pas d'atteindre les éléments de la fenêtre.
• Les utilisateurs de lecteur d'écran utilisent normalement les flèches vers le haut ou le bas pour déplacer le focus de lecture. Ils ne pourront pas le faire dans la fenêtre et ne pourront par conséquence, pas lire le contenu de celle-ci.

Néanmoins en configurant quelques options du module jQuery UI Dialog, il peut devenir accessible pour tous les utilisateurs.

Modal

Nous mettons la valeur de 'modal' à "true" pour que les autres éléments de la page cessent d'être accessibles au clavier. Vous créez ainsi une sorte de piège au clavier qui maintiendra le focus dans la boîte de dialogue. Il n'en sortira pas.

Gestion du focus

Il est très important que le focus se déplace vers la boîte de dialogue qui s'ouvre. Un utilisateur aveugle ou ayant une déficience visuelle peut penser que le lien qu'il a activé ne fonctionne pas parce qu'il y a l'air de ne rien se passer. Un utilisateur malvoyant qui travaille avec un logiciel d'agrandissement ne voit peut-être pas la fenêtre de dialogue car elle se trouve en dehors de son champ de vision. Heureusement le déplacement du focus fait bien partiue de jQUery UI.

Il faut idéalement que ce soit le premier élément de la lightbox qui reçoive le focus. En effet, on voit souvent que le premier champ de formulaire de la lightbox reçoit le focus. Or s'il y a du texte qui précède ce champ de formulaire, celui-ci ne sera pas lu par les lecteurs d'écran.

aria-hidden

On peut utiliser des propriétés ARIA pour communiquer des informations supplémentaires aux lecteurs d'écran. Dans ce contexte il peut être utile d'utiliser l'attribut aria-hidden.

L'attribut Aria-hidden est de type booléen. Aria-hidden="true" rend l'élément invisible pour un lecteur d'écran. Aria-hidden="false" le rend visible.

Nous mettons le contenu (dans ce cas un div avec id = "wrap") à aria-hidden="true". Le contenu devient alors invisible uniquement pour les lecteurs d'écrans. Pour la fenêtre de dialogue nous utilisons aria-hidden="false" pour qu'elle seule soit visible. Il ne faut pas perdre de vue que lors de la fermeture de la fenêtre, il faudra inverser les valeurs de ces deux 'aria-hidden' pour que la fenêtre soit cachée et que le contenu redevienne visible.

Exemple de code

Consultez un exemple en ligne.

Cet exemple a été teste avec les lecteurs d'écrans suivants: VoiceOver(mac) Jaws, NVDA et SuperNova (PC/Windows). Les résultats sont bons sauf en ce qui concerne SuperNova qui ne peut gérer le déplacement du focus dynamique. Les utilisateurs de SuperNova ne pourront pas consulter le contenu de la lightbox. Le focus reste bloqué sur le lien 'ouvrir la lightbox'.

Ouvrir la ligthbox.


Titre de la fenêtre de dialogue
Contenu de la fenêtre de dialogue.

$("#dialog").dialog( {
  // la fenêtre se s'affiche pas au chargement de la page.
  autoOpen : false,
  // elle ne peut être déplacée
  draggable: false,
  // nous prévoyons un bouton pour fermer cette fenêtre.
  buttons: {
    Close: function() {
      $( this ).dialog( "close" );
    }
  },
  open: function() {
    // nous ne voulons pas de barre de titre avec le bouton de fermeture.
    $(".ui-dialog-titlebar").hide();
    // le contenu sera caché aux lecteurs d'écran
    $("#wrap").attr("aria-hidden", "true");
    // la fenêtre de dialogue sera visible pour les lecteurs d'écran
    $(".ui-dialog").attr("aria-hidden", "false");
  },
  close: function() {
    // à la fermeture de la fenêtre, le contenu doit redevenir visible
    $("#wrap").attr("aria-hidden", "false");
    // et la fenêtre devient invisible
    $(".ui-dialog").attr("aria-hidden", "true");
  },
  // l'option modal:true fait que le focus reste sur la fenêtre
  // et ne sort pas de celle-ci.
  modal: true
});
// Lorsque le lien (avec id="opener") est cliqué, la fenêtre s'ouvre.
$("#opener").click(function(e) {
  // Annule le comportement par défaut du lien (scroll vers le haut de la page) 
  // lorsqu'on clique le lien.
  e.preventDefault();
  $("#dialog").dialog("open");
});

Conclusion

Moyennant quelques adaptations du code, le plugin jQuery UI Dialog devient accessible et utilisable par pratiquement tout le monde.

jQuery UI Dialog rédigé par Nicole Reyes Guttmann dans Default

]]> Mon, 04 Aug 2014 13:41:00 +0200 https://www.anysurfer.be/fr/blog/detail/jquery-ui-dialog https://www.anysurfer.be/fr/blog/detail/onclick-preferez-un-lien-ou-un-bouton?utm_source=feed&utm_medium=rss&utm_campaign=onclick-preferez-un-lien-ou-un-bouton

De plus en plus souvent, nous rencontrons des éléments cliquables qui ne reçoivent pas le focus. Les personnes qui naviguent au clavier ainsi que les utilisateurs de lecteurs d'écran ne peuvent les utiliser.

Ces éléments cliquables ne pointent pas vers une nouvelle page, mais vers des éléments internes de la page. Ils provoquent souvent des rafraîchissements partiels du contenu de la page

Quelques exemples:

• Un menu 'hamburger' pour la navigation dans un site responsive:

  Toggle navigation

• Les boutons 'fermer', 'suivant' et 'précédent' dans une lightbox:

  Fermer

• Les liens qui permettent de filtrer les résultats d'une recherche:

  Entre 1200W et 1500W

• Trier un tableau sur base du contenu du 'th':

  Date

• Le bouton corbeille qui permet d'éliminer un item de la liste de vos achats:

Les éléments

, , , … qui sont rendus interactifs via JavaScript (onclick) ne sont pas accessibles au clavier. Si vous souhaitez les rendre focusables et accessibles, vous devrez recourir à ARIA et ajouter du code JavaScript. Cette option est assez compliquée.

Il existe une solution bien plus simple: toujours utiliser un lien (a href) ou un bouton (button) qui sera couplé à du JavaScript. Un lien ou un bouton sont toujours inclus dans l'ordre de tabulation et reçoivent toujours le focus. Voici trois exemples de code qui ouvrent une fenêtre 'alert'.

a href="#"

Dans ce premier exemple, 'onclick' est utilisé comme attribut du lien:

  Exemple 1

Exemple 1

Event Listener

En utilisant un 'Event Listener' vous pouvez séparer le code JavaScript du HTML en le plaçant ailleurs dans le code source de la page ou dans un fichier séparé.

Nous utilisons ici jQuery pour coupler l'Event Listener au lien id="lien2".

  Exemple 2

Exemple 2

Dans l'attribut href

Dans cet exemple, nous n'utilisons pas d'Event Listener ou de onclick, mais nous plaçons le code JavaScript dans l'attribut href.

  Exemple 3

Exemple 3

Conseils

Il existe plusieurs façons de rendre ces éléments cliquables accessibles. Choisissez celle qui vous convient le mieux.

Evitez onMouseOver, onMouseOut, onKeyDown, onKeyUp et onDblClick qui ne fonctionnent pas pour tous les utilisateurs. Par contre OnClick est accessible si vous l'utilisez comme dans les exemples de cet article.

OnClick? Préférez un lien ou un bouton! rédigé par Nicole Reyes Guttmann dans Default

]]> Mon, 04 Aug 2014 11:27:00 +0200 https://www.anysurfer.be/fr/blog/detail/onclick-preferez-un-lien-ou-un-bouton https://www.anysurfer.be/fr/blog/detail/developper-des-apps-accessibles?utm_source=feed&utm_medium=rss&utm_campaign=pistes-pour-developper-des-apps-accessibles Les smartphones et tablettes qui tournent sur Android et iOS peuvent être bien utilisables par les personnes handicapées. Pour plus d'infos à ce sujet, voyez notre article Naviguer sur internet avec un dispositif mobile.

Vous êtes de plus en en plus nombreux à nous demander des conseils pour développer une app accessible, ou pour vérifier l'accessibilité d'une app existante. Nous voulons dans cet article vous donner quelques pistes. Vous trouverez ci-dessous quelques conseils généraux ainsi que des liens vers des ressources pour les développeurs. Nous nous limiterons pour cette fois-ci aux plateformes iOS et Android.

Pour évaluer l'accessibilité d'un site web nous nous basons sur les Web Content Accessibility Guidelines. Ces critères sont formulés indépendamment des technologies et devraient donc être utilisables pour évaluer des apps.

Quand on évalue l'accessibilité d'une app, il y a effectivement une partie des tests qui se rapprochent de ceux que l'on peut faire sur un site web. Par exemple : les boutons sont-ils bien étiquetés, les liens significatifs, les tableaux linéarisables, les validations de formulaire sont-elles claires pour ceux qui ne voient pas l'écran, etc ?

Par contre il est pour nous plus difficile de dire ce qui cause les problèmes identifiés et comment ils peuvent être résolus. Nous ne pouvons pas consulter facilement le code source comme dans un site web.

Utilisable au clavier

La première des directives AnySurfer demande que toutes les fonctionnalités soient utilisables avec le clavier. Comment cela se traduit-il dans le cas d'un écran tactile ?

Un utilisateur aveugle utilise un écran tactile d'une manière fort différente de quelqu'un qui peut voir. Les lecteurs d'écran comme VoiceOver pour iOS et Talkback pour Android font bien plus que lire ce qui est affiché à l'écran. Ils offrent tout un système d'interaction, y compris des gestes adaptés. Voyez comment cela fonctionne dans cette vidéo : balayer l'écran de gauche à droite avec un doigt déplace le focus à l'élément suivant (comme le TAB du clavier).

En tant que développeur il faut veiller à ce que ce focus puisse se déplacer à travers tous les éléments interactifs de l'app, et que ce déplacement ait lieu dans un ordre logique.

Sémantique

Utilisez le plus possible des éléments standards pour construire des éléments interactifs. Leur comportement sera alors prévisible et compréhensible quel que soit le mode d'interaction.

Les lecteurs d'écran annoncent le rôle de l'élément (case à cocher), son nom (le label du champ), et son état (cochée). Si vous programmez des éléments vous-même (par exemple une fausse case à cocher) vous devrez programmer vous-même toutes les fonctionnalités et les tester de manière approfondie (avec des lecteurs d'écran).

Les images ont une alternative textuelle

Les images d'un site web doivent avoir un attribut alt. Dans les apps les boutons doivent avoir une alternative textuelle. Le principe est le même mais la technique pour donner une alternative textuelle diffère d'un environnement de développement à l'autre.

Si vous oubliez d'étiqueter un bouton, en général c'est le nom du fichier qui est lu, au lieu de la fonction du bouton. En tant qu'utilisateur on préfère entendre "retour" que "NavBarIconBackButtonSmall".

Documentation pour les développeurs

Il existe, pour iOS ainsi que pour Android, de la documentation qui explique comment développer des applications accessibles sur ces plateformes.

• Accessibility Programming Guide for iOS : Making Your iOS App Accessible
• Android Accessibility

A côté de ces guides, il y a également les Mobile Accessibility Guidelines de la BBC, qui ont l'avantage de donner pour chaque critère les techniques pour iOS, Android et HTML.

Pistes pour développer des apps accessibles rédigé par Sophie Schuermans dans Default

]]> Tue, 01 Apr 2014 09:49:00 +0200 https://www.anysurfer.be/fr/blog/detail/developper-des-apps-accessibles https://www.anysurfer.be/fr/blog/detail/des-liens-sur-la-meme-page-qui-fonctionnent-pour-tout-le-monde?utm_source=feed&utm_medium=rss&utm_campaign=des-liens-sur-la-meme-page-qui-fonctionnent-pour-tout-le-monde Quand on utilise des liens sur la même page, comme des liens d'évitement ou les liens des tables des matières, il faut veiller à ce que ces liens fonctionnent correctement au clavier. Ce n'est pas toujours le cas.

Des liens sur la même page qui fonctionnent pour tout le monde rédigé par Sophie Schuermans dans Default

]]> Tue, 07 Jan 2014 11:30:00 +0100 https://www.anysurfer.be/fr/blog/detail/des-liens-sur-la-meme-page-qui-fonctionnent-pour-tout-le-monde https://www.anysurfer.be/fr/blog/detail/la-navigation-avec-un-dispositif-mobile-pour-les-personnes-handicapees?utm_source=feed&utm_medium=rss&utm_campaign=la-navigation-avec-un-dispositif-mobile-pour-les-personnes-handicapees 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 .

La navigation avec un dispositif mobile pour les personnes handicapées rédigé par Nicole Reyes Guttmann dans Default

]]> Thu, 31 Oct 2013 15:10:00 +0100 https://www.anysurfer.be/fr/blog/detail/la-navigation-avec-un-dispositif-mobile-pour-les-personnes-handicapees https://www.anysurfer.be/fr/blog/detail/les-operateurs-telecom-doivent-rendre-une-page-accessible?utm_source=feed&utm_medium=rss&utm_campaign=les-operateurs-telecom-doivent-rendre-une-page-accessible L'institut Belge des Postes et Télécommunications a publié le 28 mars 2013 une décision concernant la publication par les opérateurs des informations sur les produits et services destinés aux utilisateurs handicapés. Cette décision va-t-elle vraiment aider ces utilisateurs ?

Les opérateurs télécom doivent rendre une page accessible rédigé par Sophie Schuermans dans Default

]]> Fri, 04 Oct 2013 09:49:00 +0200 https://www.anysurfer.be/fr/blog/detail/les-operateurs-telecom-doivent-rendre-une-page-accessible https://www.anysurfer.be/fr/blog/detail/sous-titrer-facilement-avec-laide-de-youtube?utm_source=feed&utm_medium=rss&utm_campaign=sous-titrer-facilement-avec-laide-de-youtube

Sous-titrer facilement avec l'aide de YouTube rédigé par Sophie Schuermans dans Default

]]> Wed, 27 Mar 2013 09:00:00 +0100 https://www.anysurfer.be/fr/blog/detail/sous-titrer-facilement-avec-laide-de-youtube