Rencontrez-Vous

Les applications de rencontre grand public reposent sur deux mécaniques : le jugement rapide sur la photo, et l'autonomie totale de l'utilisateur. Les deux posent problème ici. La première exclut d'emblée des personnes dont le handicap est visible. La seconde suppose une aisance de lecture, de navigation et de mise en garde face aux abus qui n'est pas donnée à tout le monde.

Le parti pris du projet est de passer par l'institution. Une personne accède à l'application parce qu'un établissement qui la connaît lui en ouvre l'accès. L'encadrement n'est pas une contrainte ajoutée après coup : c'est la structure même du produit.

« Accessible » ne veut rien dire tant qu'on ne décrit pas ce qui est fait. Sur cette application, la première décision a été la simplicité visuelle : peu d'éléments par écran, une action principale par étape, aucune interaction cachée derrière un geste à deviner.

Les textes sont rédigés en FALC — Facile À Lire et à Comprendre. Ce n'est pas une simplification cosmétique : c'est une méthode qui impose des phrases courtes, un vocabulaire courant, une idée par phrase. Elle change la façon dont l'interface entière est écrite, pas seulement quelques libellés.

L'application est utilisable au lecteur d'écran, VoiceOver sur iOS et TalkBack sur Android. Chaque élément interactif porte un libellé explicite, l'ordre de parcours suit la logique de l'écran, et les changements d'état sont annoncés.

S'y ajoutent des réglages que l'utilisateur contrôle : contrastes renforcés, thème sombre, taille de texte, retours haptiques. Ils sont dans les paramètres de l'application, pas seulement hérités du système, parce que tout le monde ne sait pas où les modifier sur son téléphone.

Le niveau AAA est le plus exigeant des trois définis par les WCAG. Il impose notamment des contrastes de 7:1 sur le texte courant, là où le niveau AA se contente de 4,5:1, et il ferme la porte à beaucoup de choix graphiques usuels.

La conformité a été vérifiée en continu pendant le développement à l'aide d'outils d'audit automatisés, dont axe-core, plutôt qu'en contrôle final. C'est une différence de méthode importante : reprendre une interface pour l'accessibilité après coup coûte bien plus cher que de la concevoir sous contrainte dès la première maquette.

Un rapport d'audit peut être fourni sur demande.

L'accès par institution suppose que chaque établissement puisse gérer ses propres membres sans voir ceux des autres. Le back-office est donc construit sur deux niveaux : l'institution administre ses inscrits, le porteur du projet supervise l'ensemble du réseau.

Comme pour AC-PEB, cette séparation est appliquée dans la base de données et non seulement dans l'interface. Sur un produit qui traite des données de personnes vulnérables, une erreur de périmètre ne se rattrape pas par des excuses.

Côté institution, l'écran de gestion est volontairement réduit : inviter un membre, suspendre un accès, voir qui est actif. Les personnes qui utilisent ce back-office sont des éducateurs, pas des administrateurs système.

L'application n'est pas encore publiée sur les stores. Nous la présentons ici parce que le travail d'accessibilité qu'elle contient est ce que nous savons faire de plus rare, et parce qu'il est vérifiable — pas pour revendiquer des utilisateurs que nous n'avons pas.

Le porteur du projet a présenté le dispositif à des institutions du secteur, dont plusieurs se sont montrées intéressées. Nous ne publions pas de compte : ces échanges sont les siens, pas les nôtres, et un décompte d'intentions n'est pas un résultat.