Création d'applications Oracle JET accessibles

Remarque : ce parcours de formation comporte un prérequis : Développement d'une application Web dans Oracle JavaScript Extension Toolkit (Oracle JET), qui doit être terminé avant le début de ce cours.

Introduction à l'accessibilité

Maintenant que vous avez une compréhension de base de la façon d'utiliser Oracle JET pour développer des applications Web, il est temps de répondre aux besoins spécialisés de près de 10 à 20 % de votre public cible, les personnes handicapées. Selon un article publié par l'Organisation mondiale de la santé en 2014, environ 15 % de la population mondiale souffre d'une forme de handicap, et ce nombre augmente avec une population toujours plus âgée.

Historique

Le concept moderne d'accessibilité est né à la fin du 1960s en tant que mouvement de base sur les campus universitaires et dans les communautés locales pour s'attaquer aux droits des personnes handicapées qui cherchent un accès physique aux bâtiments publics. Cet accès comprenait des rampes le long des allées publiques, des entrées, des portes automatiques et des étiquettes en braille dans les ascenseurs aux bâtiments publics, gouvernementaux et universitaires.

Législation sur l'égalité d'accès

Aujourd'hui, "l'accès" intègre à la fois l'accès physique aux structures et l'accès au paysage technologique actuel des PC, ordinateurs portables, tablettes, smartphones et appareils à commande vocale tels qu'Amazon Alexa. La législation sur l'égalité d'accès continue d'aborder les questions de l'accès physique et de la technologie dont nous dépendons.

L'accessibilité des logiciels est imposée par les lois civiles dans de nombreux pays à travers le monde. Exemple :

• The Americans with Disabilities Act aux États-Unis
• Loi sur l'accessibilité pour les personnes handicapées de l'Ontario en Ontario, Canada
• The Equality Act of 2010 au Royaume-Uni

Défis d'accès - Types d'obstacles

En tant que concepteurs et développeurs d'applications Web, nous devons être conscients que les clients handicapés font face à des obstacles lorsqu'ils accèdent à la technologie. Prenez les éléments suivants en considération :

• Un utilisateur ne peut pas manipuler la souris en raison d'une mobilité réduite (maladie congénitale de la naissance, maladie de Lou Gehrig, maladie de Parkinson, polyarthrite rhumatoïde, blessure ou déficit lié au vieillissement). Comment un tel utilisateur activerait-il un texte auquel un événement de clic est lié ?
• Un utilisateur est malvoyant et ne peut pas voir que les instructions pour utiliser une page ou un formulaire suivent après le contenu. Comment l'utilisateur sait-il lire la page entière pour trouver les instructions ?
• Un utilisateur a une faible vision et utilise une loupe d'écran qui se concentre sur et n'agrandit qu'une petite partie de l'écran à la fois. Compte tenu des limites de la loupe, comment l'utilisateur pourrait-il savoir si un message apparaît ailleurs à l'écran ?
• Un utilisateur est daltonien et ne peut pas distinguer certaines couleurs. Comment l'utilisateur pourrait-il savoir quel est le bouton rouge, bleu ou vert référencé dans le texte de la page ?

Ce ne sont là que quelques exemples des préoccupations qu'un développeur doit résoudre lors de la création d'une application Web accessible. Ce parcours pédagogique fournit des méthodes claires de codage et de test d'accessibilité afin de se conformer aux normes les plus récentes définies par la version 2.2 des Directives d'accessibilité des contenus Web (WCAG).

Il est prudent d'examiner de près les lignes directrices mentionnées ci-dessus, car elles constituent la base de notre travail en matière d'accessibilité.

Directives d'accessibilité du contenu Web (WCAG)

Le World Wide Web Consortium (W3C) a créé un ensemble de normes appelé Web Content Accessibility Guidelines (WCAG) qui fournissent des règles très spécifiques pour rendre les sites Web et les applications Web accessibles. Ces directives constituent la base de ce parcours pédagogique.

Les normes WCAG se concentrent sur quatre domaines d'une application Web ou d'un site Web :

1. Percevabilité : L'interface peut-elle être perçue par une grande majorité de personnes, indépendamment de leur handicap ?

   • Les rapports de contraste de couleur qui fonctionnent bien pour ceux avec la basse vision
   • Simplicité de mise en page qui fonctionne bien pour ceux qui ont des déficits cognitifs

2. Opérabilité : Les personnes peuvent-elles interagir avec l'interface indépendamment des handicaps ?

   • Accès au clavier uniquement : naviguer et utiliser l'interface sans utiliser de souris
   • Accès vocal uniquement : opère l'interface par saisie vocale uniquement

3. Compréhension : L'interface est-elle facilement comprise par les personnes, indépendamment des handicaps ?

   • Le contenu est écrit pour être compris par les personnes ayant des déficiences cognitives
   • L'interface est comprise par un individu utilisant un lecteur d'écran

4. Robustesse : l'interface prend-elle en charge une variété d'agents utilisateurs (navigateurs, appareils et technologies d'assistance) ?

Si les critères WCAG sont remplis, les applications Web et les sites Web doivent également satisfaire à toutes les exigences légales.

Le coût de l'accessibilité

Notez que l'accessibilité ne doit jamais être repensée après coup lors de l'écriture de code. Bien que le processus de développement soit plus long, il est plus rentable d'écrire des fonctionnalités d'accessibilité dans le code pendant la phase de développement que de modifier une application existante.

Les développeurs se plaignent souvent de la nécessité de répondre aux besoins particuliers d'une population sans doute petite. Lorsqu'il est implémenté correctement, le code accessible facilite l'utilisation d'une application pour tous, et pas seulement pour les personnes handicapées. Par exemple, en simplifiant l'interface et en choisissant des couleurs avec des rapports de contraste plus élevés, les applications sur les appareils mobiles ou les navigateurs plus anciens sont plus simples à utiliser.

1, 2, 3 étapes pour réussir

L'accessibilité commence à la phase de conception. Les concepteurs créent un modèle de base de ce que fait le programme. Ils devraient tisser l'accessibilité tout au long de la conception pour s'assurer que le plan comprend des mécanismes efficaces pour l'accès au clavier uniquement. Ce type d'accès permet d'utiliser d'autres dispositifs d'entrée pour ceux dont les mains sont limitées ou inutilisées.

Les développeurs doivent avoir à la fois une solide connaissance pratique de la façon de coder pour l'accessibilité (front-end) et une connaissance technique de la façon de tester pour l'accessibilité (back-end).

Les ingénieurs en assurance de la qualité (AQ) doivent parler le langage de l'accessibilité. Comme les développeurs, ils doivent comprendre et effectuer des tests d'accessibilité en plus des tests normaux de fonctionnalité et de sécurité. Les professionnels de l'assurance de la qualité sont le tampon entre le logiciel qui est libéré et le potentiel de litige si les directives d'accessibilité ne sont pas respectées.

Notes à l'avis

Oracle JET est ouvert au public pour être utilisé dans des applications et des sites Web autres qu'Oracle. Par conséquent, la version WCAG 2.2 doit être respectée lors de l'écriture d'applications Oracle JET.

Ce parcours d'apprentissage se concentre principalement sur les aspects de l'accessibilité qui s'appliquent à l'accès au clavier et à l'utilisation du lecteur d'écran. Ce chemin ne se concentre pas sur les aspects cognitifs de la conception ou de la création d'une application Oracle JET.