Trois recommandations pratiques du team chargé du développement de l’appli « Inclusive CFF » pour un front-end inclusif.

En décembre 2020, les CFF lançaient l’appli Inclusive CFF, qui avait initialement pour vocation de numériser les informations clientèle visuelles dans les gares et les trains du trafic grandes lignes des CFF afin de les diffuser sur le smartphone personnel des client·e·s. Elle a ainsi rendu lisibles et audibles les informations de voyage essentielles pour les personnes souffrant d’un handicap visuel. Depuis, l’appli Inclusive CFF s’est enrichie de nouvelles fonctionnalités: un localisateur de bouton de porte a été installé, les informations clientèle affichées aux arrêts de tram et de bus y ont été intégrées et les annonces diffusées en gare y sont retranscrites sous forme de texte. C’est pourquoi l’appli, de plus en plus utilisée par les personnes malentendantes également, est devenue aujourd’hui un assistant de voyage pour l’ensemble des voyageurs et voyageuses en situation de handicap.L’appli Inclusive CFF a été récompensée à plusieurs reprises. Elle a remporté le Prix de la Canne Blanche 2020 remis par l’UCBA ainsi que le Participants Award décerné lors des UIC International Sustainable Railway Awards 2022. CFF Inclusive est aussi la toute première application à avoir été certifiée en 2022 par la fondation «Accès pour tous».

Mais quels sont les critères à prendre en compte dans le front-end en vue de rendre une application facile d’utilisation pour les personnes souffrant d’un handicap visuel? L’exercice est à la fois passionnant et exigeant. Le team en charge du développement d’Inclusive CFF a beaucoup appris ces quatre dernières années: de la part des utilisateur·trice·s tests ayant une déficience visuelle mais également de leurs propres tests réalisés avec différentes fonctions d’assistance. Ses trois principales recommandations sont présentées ci-dessous et illustrées par des exemples tirés du code:

Recommandation n° 1 : prendre en charge l’agrandissement des contenus.

Il est facile d’éviter les textes tronqués.

De nombreux utilisateurs et utilisatrices en situation de handicap visuel utilisent l’option d’agrandissement du texte proposée par le système d’exploitation. Il est par conséquent important que l’appli puisse prendre en charge les différentes tailles de contenu.

Lors de tests réalisés avec une application présentant des textes agrandis, il arrive régulièrement que certains contenus soient tronqués. Dans la plupart des cas, il suffit d’autoriser l’application à afficher des textes de plusieurs lignes pour remédier à ce problème.

Text("...")
    .fixedSize(horizontal: false, vertical: true)

// Flutter
Text(‘…’), // it usually just works ¯\_(ツ)_/¯
// but use Expanded for Text in a Row
Row(
    children: <Widget>[
        Expanded(
            child: Text(‘…’),
        ),
    ],
)

Mais cette possibilité n’est parfois pas souhaitable, notamment pour les boutons. Il est dès lors judicieux, d’une part, de choisir des libellés aussi courts que possible et, d’autre part, de limiter – à titre de compromis – la taille maximale des caractères pour certains textes et de laisser au système d’exploitation le soin de l’affichage. Toutefois, pour les personnes à l’acuité visuelle réduite, une limitation de la taille des caractères n’est pas idéale dans la mesure où le texte pourrait s’afficher dans une police de caractères trop petite pour elles. Il est donc recommandé, dans la mesure du possible, de raccourcir les libellés, de disposer différemment les boutons dans le design ou d’autoriser les contenus de plusieurs lignes.

Text(“…”)
    .minimumScaleFactor(0.1)

AutoSizeText(    // Use this awesome plugin
    '...',
    maxLines: 1,
    minFontSize: 1,
)

Dans de nombreux cas, l’agrandissement des contenus ne permet plus l’affichage intégral du texte sur l’écran. Les utilisateur·trice·s souffrant d’un handicap visuel rencontrent fréquemment ce problème. Il est donc recommandé, lorsqu’un texte risque de s’étendre sur plusieurs lignes suite à un fort agrandissement de sa taille, de configurer des vues déroulantes.

Autre disposition des éléments pour des contenus agrandis.

Malheureusement, même les designs les plus simples ne fonctionnent pas toujours pour toutes les tailles de texte. Dans ce cas, il est conseillé de créer une autre variante de mise en page qui permette de modifier la disposition des éléments en fonction de la taille du contenu. Il peut notamment s’avérer utile de masquer les icônes pour réserver davantage d’espace aux informations plus importantes.

@Environment(\.sizeCategory) var sizeCategory

if SizeCategories.accessibility.contains(sizeCategory) {
    TrainConnectionRowAccessibility(…)
} else {
    TrainConnectionRowNormal(…)
}

final mq = MediaQuery.of(context);// Decide for yourself when to switch
if (mq.size.width <= 330 || mq.textScaleFactor >= 1.4) {
    TrainConnectionRowAccessibility();
} else {
    TrainConnectionRowNormal();
}

Recommandation n° 2 : sélectionner les couleurs avec circonspection.

Pour les personnes avec un handicap visuel, l’application doit garantir une bonne qualité de contrastes pour être performante. Il est recommandé d’utiliser une palette de couleurs avec un nombre limité de nuances soigneusement sélectionnées. Idéalement, on y trouvera des couleurs de premier plan et d’arrière-plan présentant un fort contraste les unes par rapport aux autres.

De nombreux utilisateurs et utilisatrices avec un acuité visuelle réduite utilisent le mode sombre pour éviter l’éblouissement. Pour la mise en œuvre, le team chargé du développement de l’appli Inclusive CFF a mis au point une série de couleurs sémantiques. Une couleur sémantique est toujours utilisée pour un usage précis. Exemple: la couleur textBlack est réservée à tous les textes ordinaires de l’appli. Un couple chromatique est ensuite attribué à la couleur sémantique pour le mode clair et le mode sombre. La palette de couleurs n’est ainsi définie qu’une seule fois et sera systématiquement appliquée de la même manière dans toute l’application.

Text(“Bern”)
    .foregroundColor(SBBColor.textBlack)

Text(
    ‘Bern’,
    style: Theme.of(context).textTheme.bodyText1
        .copyWith(color: SBBColors.textBlack),
);

Recommandation n° 3 : optimiser l’affichage pour les lecteurs d’écran.

Se familiariser avec les lecteurs d’écran.

VoiceOver et TalkBack sont d’autres éléments importants à prendre en compte lors de la programmation d’une appli accessible aux personnes en situation de handicap. En tant que développeur ou développeuse, il est conseillé d’utiliser soi-même régulièrement les lecteurs d’écran et de les configurer sous la forme de raccourcis sur son propre appareil. Cela permet d’avoir une idée concrète de ce qui est véritablement important pour garantir une bonne utilisation de l’application. À cet égard, il est recommandé de prendre également en compte les feed-back des utilisateurs et utilisatrices tests, ces personnes maîtrisant parfaitement l’usage du smartphone avec leur handicap.

Masquer les informations visuelles non essentielles.

VoiceOver et TalkBack lisent à haute voix chacun des éléments visuels affichés sur l’écran. Mais cette fonctionnalité n’est pas toujours utile, notamment lorsqu’une appli a souvent recours à des symboles ou à des images pour illustrer le texte. La répétition ainsi engendrée est superflue pour les personnes utilisant un lecteur d’écran. Il convient donc, dans ce cas, de masquer ce type d’informations.

Image(”train-small”)
    .accessibilityHidden(true)

Image.asset(
    Images.trainSmall,
    excludeFromSemantics: true,
)

Fournir des textes mieux adaptés aux lecteurs d’écran.

Souvent, l’information proprement dite ne devient claire qu’une fois ses différents éléments assemblés. Il est donc important d’associer ces données entre elles pour les lecteurs d’écran également.

Group {
    Text("12:39")
    Text("12:40")
    …
}.accessibilityElement(children: .combine)

MergeSemantics(
    child: Column(
        children: const <Widget>[
            Text('12:39'),
            Text('12:40'),
            …
        ],
    ),
),

Un design est considéré intelligent lorsqu’il fournit un contexte aux informations représentées sans le mentionner explicitement. L’écran ci-dessous en donne un exemple: au vu de l’ordre d’affichage des données, on peut en déduire que le train arrive à Flawil à 12h39 et en repart à 12h40. Ces informations ne sont toutefois pas explicitement communiquées par le biais de textes. Pour les personnes utilisant un lecteur d’écran, ces corrélations visuelles font défaut. On ajoutera donc des éléments de liaison sous la forme de textes supplémentaires.

Mais pour ce faire, l’ajout d’un simple attribut au code ne suffit pas. Il est de ce fait conseillé de configurer un TextFormatter défini par l’utilisateur·trice, lequel prendra en charge la mise à disposition de textes pertinents.

Group {
    …
}
    .accessibilityLabel(Text(TextFormatter.stopStation(for: stopStation).voiceover))

Semantics(
    value: createSemantics(stopStation),
    child: …,
)

Pour accéder plus rapidement au contenu souhaité, les lecteurs d’écran permettent la navigation de titre en titre. Ceux-ci doivent donc être identifiés en conséquence dans le code.

Text(”Einstellungen")
    .accessibilityAddTraits(.isHeader)

Semantics(
    header: true,
    child: Text('Einstellungen'),
)

Bien que les lecteurs d’écran soient très performants, tant sous iOS que sous Android, il est parfois nécessaire de leur donner un coup de pouce. C’est notamment le cas avec les horaires affichés par défaut de manière peu compréhensible.

Text(trainConnection.departureTime)
    .accessibilityValue(DateFormatter.hourMinuteVoiceoverTime.string(from: trainConnection.departureTime))

Identifier les cas où VoiceOver et TalkBack ne sont pas parfaits demande la réalisation de tests réguliers par tous les membres du team de développement.

En résumé.

Concevoir une application accessible n’est pas si complexe dès lors que les principes essentiels de l’accessibilité numérique sont connus et pris en considération. Il est important d’intégrer ces principes dès la phase de conception et de sensibiliser le team de développement en conséquence. Le travail de programmation supplémentaire sera ainsi minime. En outre, l’application s’adressera dès son lancement à un public potentiellement plus large, dans la mesure où les personnes en situation de handicap pourront également l’utiliser de manière intuitive. L’accessibilité numérique offre un voyage passionnant et instructif à forte valeur ajoutée, aussi bien pour les utilisateur·trice·s que pour les teams de développement.

Information à propos des auteur·e·s

Ce texte a été publié pour la première fois en août 2020, en anglais, sur le blog Medium de l’AppBakery des CFF. La présente version a été actualisée et remaniée.

Reto Allemann travaille en tant que Product Owner de l’appli Inclusive CFF. Il est en outre responsable de l’innovation et accompagne les teams dans le cadre d’organisations de travail agiles.

Nicolas Brunner a occupé jusqu’en 2022 la fonction de développeur iOS de l’appli Inclusive CFF. En août 2020, il a par ailleurs publié la version de base de cet article dans un blog paru sur Medium.

Jeanne Fleury travaille depuis 2022 en qualité de développeuse iOS de l’appli Inclusive CFF.

Les développeur·euse·s de l’appli Inclusive CFF travaillent pour le compte de l’AppBakery, une agence interne aux CFF chargée de créer des solutions innovantes à partir de nouvelles technologies.