Accessibility on Linux is uneven. Some parts are genuinely good, some are thin, and the Wayland transition changed the architecture in ways that are still being worked through.

This covers what exists and where the gaps are.

AT-SPI: the layer everything depends on

AT-SPI, the Assistive Technology Service Provider Interface, is a D-Bus protocol through which applications expose their interface as a structured tree: this is a button, its label is “Save”, it is enabled, it has focus.

A screen reader reads that tree. It does not read the screen.

This is the fact that determines everything else. An application that does not implement AT-SPI is invisible to assistive technology regardless of how clear it looks, and a custom-drawn widget with no accessibility metadata is a blank to a screen reader even though a sighted user sees a labelled button.

sudo apt install accerciser
accerciser

Accerciser shows the AT-SPI tree of any running application, which is how you find out whether something is exposed properly. If a control does not appear there, no assistive tool can reach it.

gsettings get org.gnome.desktop.interface toolkit-accessibility
gsettings set org.gnome.desktop.interface toolkit-accessibility true

Orca

The screen reader.

sudo apt install orca
orca

GNOME toggles it with Super+Alt+S. orca -s opens preferences.

Orca speaks through speech-dispatcher, which abstracts the synthesiser:

sudo apt install speech-dispatcher espeak-ng
spd-say "testing"

espeak-ng is the common default: fast, responsive, and robotic. Experienced screen reader users frequently prefer it and run it at speeds a newcomer finds unintelligible, because responsiveness matters more than pleasantness when it is your primary interface.

For a more natural voice, speech-dispatcher supports several backends including Piper, which produces markedly better quality at some latency cost.

Braille works through BRLTTY:

sudo apt install brltty

It supports a wide range of refreshable displays and works in the console as well as the desktop.

Magnification

Built into GNOME and KDE.

gsettings set org.gnome.desktop.a11y.applications screen-magnifier-enabled true
gsettings set org.gnome.desktop.a11y.magnifier mag-factor 2.0
gsettings set org.gnome.desktop.a11y.magnifier mouse-tracking 'proportional'

Full-screen and lens modes, with adjustable tracking, colour inversion, and crosshairs.

Related but distinct: display scaling for users who need everything larger rather than a magnified region. Our HiDPI and fractional scaling guide covers that, and a larger interface at high resolution is frequently a better answer than magnification for low vision.

Font size independently of scaling:

gsettings set org.gnome.desktop.interface text-scaling-factor 1.25

Input

Mouse keys move the pointer with the numeric keypad.

Sticky keys let modifier combinations be pressed in sequence rather than held, which matters for anyone who cannot hold two keys at once.

Slow keys require a key to be held briefly before registering, filtering unintended presses.

Bounce keys ignore rapid repeats, which helps with tremor.

Dwell clicking clicks when the pointer rests in one place. This is the one that determines whether a computer is usable at all for someone who can move a pointer but cannot click, including users of head and eye tracking. Plasma 6.8 added it as a built-in feature, which matters because under Wayland it has to be built in.

gsettings set org.gnome.desktop.a11y.mouse dwell-click-enabled true
gsettings set org.gnome.desktop.a11y.mouse dwell-time 1.2
gsettings set org.gnome.desktop.a11y.keyboard stickykeys-enable true

On-screen keyboards: GNOME has one built in, and Onboard is the more configurable alternative with scanning support for switch access.

What Wayland changed

Under X11, any client with display access could read the entire screen and inject input events. That made assistive tools straightforward to write as external programs, and it was a serious security flaw: any application could silently log every keystroke in every other window.

Wayland removed it deliberately. A client sees its own surfaces and nothing else.

The consequence for accessibility is structural: features that used to be external programs must now be provided by the compositor, because nothing else has the necessary access.

This has three effects.

Each desktop must implement each feature separately. Dwell clicking in GNOME and dwell clicking in Plasma are separate implementations, and a feature can exist in one and not the other.

Some X11 tools simply stopped working. Anything relying on global input injection or screen reading.

Smaller compositors have very little. Sway, Hyprland, and river offer essentially no accessibility features, because implementing them is substantial work for a small project.

AT-SPI itself works under Wayland, so Orca functions. The input and screen-reading capabilities around it are what had to be rebuilt.

Our Wayland and X11 explainer covers the underlying difference, and the same tradeoff appears in screen recording and Flatpak sandboxing.

The state of each desktop

GNOME has the best support by a clear margin. Sustained investment, Orca developed alongside it, and accessibility treated as part of the design rather than a feature area.

KDE Plasma has improved substantially and continues to. The recent dwell clicking and auto-scrolling work is real progress, and it was behind GNOME for a long time.

Xfce, MATE, Cinnamon have basic support, mostly inherited from GTK, and little beyond that.

Tiling compositors have very little. This is worth stating plainly, because a keyboard-driven interface sounds as though it would suit users who cannot use a mouse, and the absence of screen reader integration means it frequently does not.

Applications

GTK and Qt applications generally work, because the toolkits implement AT-SPI.

Electron applications depend on Chromium’s accessibility support being enabled and correctly bridged to AT-SPI. Results vary considerably between applications.

Java applications need the Java Access Bridge, which is frequently not enabled by default.

Terminal applications are a mixed picture. Orca reads terminal output, and complex TUI layouts with panes and dynamic redrawing are difficult to follow. Many blind developers work in the terminal successfully, with editor and tool choices adapted to that.

Web applications depend on the site’s own accessibility, which the browser exposes through AT-SPI. A well-built site works well; a poorly-built one does not, and that is not a Linux problem.

Testing your own work

If you build software:

accerciser                    # inspect your AT-SPI tree
orca                          # actually use your application with it

Turn on Orca and try to complete a task in your application without looking at the screen. It takes ten minutes and it finds problems that no checklist does: unlabelled buttons, focus that jumps unpredictably, state changes that are never announced, and dialogs that trap focus.

Most accessibility failures are not deliberate. They are the result of nobody ever having tried.

Frequently Asked Questions

What is the main screen reader on Linux?

Orca, which is included with GNOME and works on other desktops. It reads interface elements and text aloud through speech-dispatcher and supports refreshable braille displays through BRLTTY. Toggle it with Super plus Alt plus S on GNOME.

What is AT-SPI and why does it matter?

AT-SPI is the Assistive Technology Service Provider Interface, a D-Bus protocol through which applications expose their interface structure to assistive tools. A screen reader reads that tree rather than the pixels, which is why an application that does not implement AT-SPI is unreadable no matter how clear it looks.

Did Wayland make Linux accessibility worse?

It changed how it has to work. X11 allowed any client to observe and inject input, which made assistive tools easy to write and was a serious security flaw. Under Wayland those capabilities must be provided by the compositor, so features that used to be external programs now have to be built into each desktop.

Which desktop environment has the best accessibility?

GNOME, by a clear margin, because it has had sustained investment and Orca is developed alongside it. KDE Plasma has improved substantially and recently added built-in dwell clicking and auto-scrolling. Lighter desktops and tiling compositors generally have very limited support.

Why do Electron and Java applications work poorly with a screen reader?

Both need to bridge their own accessibility model to AT-SPI, and the bridges are incomplete. Electron applications depend on Chromium’s accessibility support being enabled and correctly mapped, while Java applications need the Java Access Bridge, which is frequently not configured by default.

How do I control the mouse pointer without a mouse?

Mouse keys let the numeric keypad move the pointer and click, and every major desktop offers it in accessibility settings. For users who can move a pointer but not click reliably, dwell clicking triggers a click when the pointer rests in one place, which Plasma 6.8 added as a built-in feature.