Desktop applications are held to the same accessibility expectations as any other software: people navigate them with a keyboard alone, with a screen reader, with reduced vision, or with limited fine motor control. Unlike a website, a desktop app can't rely on a browser's built-in accessibility tree the same way — how well it works depends heavily on the underlying UI toolkit and how carefully it's used.
Keyboard navigation
Every interactive element — buttons, form fields, menus, tabs — needs to be reachable and operable using only the keyboard: Tab to move focus forward, Shift+Tab to move backward, Enter or Space to activate, and arrow keys where a composite widget (like a tab list or menu) expects them. A visible focus indicator is not optional; if a sighted keyboard user can't tell what currently has focus, the interface is not usable without a mouse regardless of what technically works.
Screen reader support
Whether an app is built with a native UI toolkit or an embedded web view, every control needs an accessible name, a role, and, where relevant, a state (checked, expanded, disabled). For web content specifically, this means using semantic HTML elements (buttons, labelled form fields, headings in order) before reaching for ARIA attributes, since native semantics are handled correctly by assistive technology automatically, while ARIA has to be applied correctly by hand to work at all.
Color and contrast
Text needs sufficient contrast against its background — commonly measured against the WCAG 2.1 thresholds of 4.5:1 for normal text and 3:1 for large text. Status or error states should never rely on color alone (a red border with no icon or text label, for example, is invisible information to someone who can't distinguish that color). Dark-themed interfaces in particular need to double-check contrast carefully, since a dark background with a similarly dark accent color can fail contrast checks even when it looks fine to a sighted designer at a glance.
Motion and animation
Where an interface uses animation, it should respect the operating system's reduced-motion
preference. For a WebView2-hosted interface, this maps directly to the CSS
prefers-reduced-motion media feature; for a native UI toolkit, most modern
frameworks expose an equivalent system setting.
Testing, realistically
- Unplug the mouse and try to complete the app's core task using only the keyboard.
- Turn on the platform's built-in screen reader (Narrator on Windows, VoiceOver on macOS) and listen to how the interface is announced.
- Run an automated contrast checker over the color palette before it's finalized, not after.
- Zoom the interface to 200% and confirm nothing is clipped or unreachable.
None of these checks require a large budget or specialized tooling — they mostly require actually doing them before a release, rather than treating accessibility as a nice-to-have that gets revisited later.
Related reading: WebView2 application packaging and Accessibility considerations for software founders.