egui/docs/accessibility.md

Accessibility

egui can expose its widget tree through AccessKit. When using eframe, AccessKit support is enabled by default on native platforms where an adapter is available. Integrations that build directly on egui can opt in with Context::enable_accesskit() before running frames.

Labels

Most built-in widgets register their role and accessible name when shown through the usual egui APIs. Buttons, checkboxes, radio buttons, sliders, combo boxes, text edits, links, windows, images, and progress indicators all contribute widget information to the AccessKit tree.

For inputs with a separate visible label, connect the input response to the label:

let label = ui.label("User name:");
ui.text_edit_singleline(&mut user_name).labelled_by(label.id);

Custom widgets

If a widget is visual-only or draws custom shapes, give it explicit widget information:

use egui::{Role, Sense, WidgetInfo};

let (_rect, response) = ui.allocate_exact_size(size, Sense::click());
// Paint using ui.painter().
response.widget_info(|| {
    WidgetInfo::labeled(Role::Button, ui.is_enabled(), "Open color picker")
});

Choose the closest egui::Role. For non-interactive custom content, prefer a label or image role where possible rather than leaving the node unnamed.

Testing

egui_kittest builds on AccessKit, so tests can query the same roles and names that screen readers consume:

use egui::Role;
use egui_kittest::{Harness, kittest::Queryable as _};

let mut harness = Harness::new_ui_state(
    |ui, accepted| {
        ui.checkbox(accepted, "Accept terms");
    },
    false,
);

harness
    .get_by_role_and_label(Role::CheckBox, "Accept terms")
    .click();
harness.run();

assert!(*harness.state());

You can also inspect the tree in the demo app when it is built with the accessibility_inspector feature.