Accessibility in Rust: How to Make Code Friendly for Everyone

Why Accessibility in Rust Is Not an Option, But a Necessity

When we write in Rust, we are used to thinking about memory safety, speed, and zero-cost abstractions. But there is another aspect that often remains behind the scenes — accessibility. Many developers think this is only the concern of frontend developers or designers. In reality, everyone who writes code in Rust can make their tools, libraries, or web applications convenient for people with disabilities.

According to WHO, more than 1 billion people in the world have some form of disability. This is a huge audience that we lose if we ignore inclusivity in Rust. And it's not just about blind users — accessibility helps everyone: from people with temporary injuries to those working in noisy environments or while driving.

In this article, we will look at how to implement a11y (short for accessibility) in Rust projects of different types: CLI utilities, web applications, and GUI. You will see real code examples that you can immediately use in your projects.

Accessibility in CLI: Making the Console Convenient for Everyone

It would seem that the terminal is the last place where accessibility is needed. But this is precisely where people with visual or motor impairments often work. Rust CLI accessibility starts with simple things:

• Clear error messages — use eprintln! for error output so they can be separately redirected to a log or read by a screen reader.
• Color schemes — do not rely solely on color. Add symbols or text: [OK], [ERROR].
• Understandable output — avoid complex tables without labels.

Here is an example of a minimalistic CLI tool in Rust with accessibility in mind:

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

fn main() {    print!("Enter your name: ");    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!("[ERROR] Name cannot be empty.");        std::process::exit(1);    }

    println!("[OK] Hello, {}! Glad to see you.", name);}

Notice: we use eprintln! for errors — this is the standard way for Rust CLI accessibility. The user can redirect stderr to a separate stream or file, and screen readers process such output more easily.

Web Accessibility in Rust: Yew and WASM

Modern web frameworks in Rust, such as Yew, Leptos, or Dioxus, allow creating full-fledged SPAs. And here Rust web accessibility is not just about tags, but an architectural decision.

The main principles of WCAG (Web Content Accessibility Guidelines) that need to be followed:

• Contrast — text should be well readable against the background.
• Keyboard navigation — all elements should be accessible via Tab.
• ARIA attributes — additional labels for screen readers.
• Semantic markup — use correct HTML tags.

Example of a Yew component with ARIA attributes in Rust:

use yew::prelude::*;

#[function_component(AccessibleButton)]pub fn accessible_button() -> Html {    html! {        <button            class="btn btn-primary"            aria-label="Submit form"            role="button"            tabindex="0"            onkeypress={|e| {                if e.key() == "Enter" || e.key() == " " {                    // Handle click                }            }}        >            { "Submit" }