Accessibilité en Rust : comment rendre le code convivial pour tous

Pourquoi l'accessibilité en Rust n'est pas une option, mais une nécessité

Lorsque nous écrivons en Rust, nous avons l'habitude de penser à la sécurité mémoire, à la vitesse et aux abstractions sans coût. Mais il y a un autre aspect qui reste souvent dans l'ombre — l'accessibilité. De nombreux développeurs pensent que cela ne concerne que les développeurs front-end ou les designers. En réalité, toute personne qui écrit du code en Rust peut rendre ses outils, bibliothèques ou applications web accessibles aux personnes handicapées.

Selon l'OMS, plus d'un milliard de personnes dans le monde ont une forme ou une autre de handicap. C'est un public immense que nous perdons si nous ignorons l'inclusivité en Rust. Et il ne s'agit pas seulement des utilisateurs aveugles — l'accessibilité aide tout le monde : des personnes ayant des blessures temporaires à celles qui travaillent dans un environnement bruyant ou au volant.

Dans cet article, nous allons voir comment intégrer l'a11y (abréviation d'accessibilité) dans les projets Rust de différents types : utilitaires CLI, applications web et GUI. Vous verrez des exemples de code concrets que vous pouvez utiliser immédiatement dans vos projets.

Accessibilité dans les CLI : rendre la console pratique pour tous

Le terminal semble être le dernier endroit où l'accessibilité est nécessaire. Mais c'est précisément là que travaillent souvent les personnes ayant des troubles de la vision ou de la motricité. L'accessibilité des CLI Rust commence par des choses simples :

• Messages d'erreur clairs — utilisez eprintln! pour afficher les erreurs, afin qu'elles puissent être redirigées séparément vers un journal ou lues par un lecteur d'écran.
• Schémas de couleurs — ne vous fiez pas uniquement à la couleur. Ajoutez des symboles ou du texte : [OK], [ERREUR].
• Sortie compréhensible — évitez les tableaux complexes sans légendes.

Voici un exemple d'outil CLI minimaliste en Rust tenant compte de l'accessibilité :

use std::io::{self, Write};

fn main() {    print!("Entrez votre nom : ");    io::stdout().flush().unwrap();

    let mut name = String::new();    io::stdin().read_line(&mut name).unwrap();    let name = name.trim();

    if name.is_empty() {        eprintln!("[ERREUR] Le nom ne peut pas être vide.");        std::process::exit(1);    }

    println!("[OK] Bonjour, {} ! Nous sommes ravis de vous voir.", name);}

Remarquez que nous utilisons eprintln! pour les erreurs — c'est la méthode standard pour l'accessibilité dans les CLI Rust. L'utilisateur peut rediriger stderr vers un flux ou un fichier séparé, et les lecteurs d'écran traitent plus facilement ce type de sortie.

Accessibilité web en Rust : Yew et WASM

Les frameworks web modernes en Rust, comme Yew, Leptos ou Dioxus, permettent de créer des SPA complètes. Et ici, l'accessibilité web Rust n'est pas qu'une question de balises, mais une décision architecturale.

Les principes de base des WCAG (Web Content Accessibility Guidelines) à respecter :

• Contraste — le texte doit être bien lisible sur son arrière-plan.
• Navigation au clavier — tous les éléments doivent être accessibles via la touche Tab.
• Attributs ARIA — des étiquettes supplémentaires pour les lecteurs d'écran.
• Balisage sémantique — utilisez les bonnes balises HTML.

Exemple de composant Yew avec attributs ARIA en Rust :

use yew::prelude::*;

#[function_component(AccessibleButton)]pub fn accessible_button() -> Html {    html! {        <button            class="btn btn-primary"            aria-label="Soumettre le formulaire"            role="button"            tabindex="0"            onkeypress={|e| {                if e.key() == "Enter" || e.key() == " " {                    // Gestion du clic                }            }}        >            { "Soumettre" }