Operating System and Desktop Software Accessibility Under the EAA: The Rules Web Teams Overlook

Ask a compliance team what the EAA covers and you'll get "websites and apps" almost every time. That's not wrong, but it's incomplete in a specific way: the EAA also names consumer general-purpose computing hardware and its operating systems as their own product category, sitting alongside smartphones, tablets, self-service terminals, e-readers, and TV equipment with digital services. Native desktop software - the kind that isn't running in a browser - inherits that obligation, and it's tested completely differently from a website.

A different product category, not a subset of "apps"

It's worth being precise about the scope, because "software accessibility" gets used loosely. The EAA's coverage of consumer computers and operating systems is not the same obligation as its coverage of mobile applications, which this site has covered separately. A mobile app ships inside an OS that already provides accessibility services (VoiceOver, TalkBack); a desktop application built with custom-drawn UI can bypass those services entirely if it isn't built against the platform's accessibility APIs. That's the crux of why this category needs its own compliance treatment.

Compliance is still measured against EN 301 549, which incorporates WCAG 2.1 AA as its baseline - and a new v4.1.1 revision, expected to publish in 2026, will fold in WCAG 2.2. But WCAG's success criteria were written with the web's DOM in mind. Applying them to native software requires translating each criterion to a platform without a DOM, without a browser's built-in accessibility tree, and often without HTML semantics of any kind.

What "operating system accessibility" means in practice for a vendor

Assistive technology compatibility through platform APIs, not custom rendering. This is the single biggest failure mode. A desktop app built with a custom UI toolkit that paints its own buttons, menus, and dialogs - rather than using native OS controls or exposing itself through the platform's accessibility layer - is often completely invisible to a screen reader, no matter how visually polished it looks. The fix isn't a web accessibility technique; it's building against the platform's accessibility API:

• Windows: UI Automation^[2] (UIA), the modern successor to Microsoft Active Accessibility (MSAA), exposes control types, names, states, and relationships to assistive technology.
• macOS: NSAccessibility protocol conformance is what lets VoiceOver read and interact with an app's controls.
• Linux: AT-SPI (Assistive Technology Service Provider Interface) plays the equivalent role for GNOME/GTK and Qt applications.

If a control isn't exposed through one of these, it does not exist for a screen reader user - regardless of what WCAG checklist item you're trying to satisfy.

Keyboard-only operability across the entire application. Every menu, dialog, modal, and custom control needs a keyboard path with a visible, logical focus order. This is the same principle as web keyboard accessibility, but desktop applications tend to have far more custom widgets - canvases, custom grids, drag-and-drop panels - where keyboard support was never designed in from the start.

Accessible installers and first-run setup. The installer is often the very first interaction a user has with the product, and it's frequently the least accessible part of it - unlabeled buttons, license-agreement text boxes that don't get focus, progress dialogs with no accessible status updates. An installer that a screen-reader user can't complete blocks them before the product itself is even relevant.

Accessible in-app help and error messaging. Error dialogs and inline validation need to be exposed to assistive technology as they appear, not just visually - the desktop equivalent of an ARIA live region. Help documentation embedded in the app should follow the same structural and readability principles as any other content.

Screen magnification and voice control compatibility. Beyond screen readers, operating-system accessibility features like screen magnifiers and voice control (Voice Access on Windows, Voice Control on macOS) need custom UI elements to behave predictably - magnifiers need standard rendering to track focus correctly, and voice control needs accessible names to map spoken commands to controls.

Why this needs a different test plan than your web team runs

Web accessibility testing leans on tools that inspect the DOM and automated scanners that catch a meaningful share of issues before manual testing even starts. None of that tooling applies to native software. There's no DOM to scan. Testing a desktop application means pairing it with the actual platform assistive technology - NVDA or JAWS with UIA on Windows, VoiceOver with NSAccessibility on macOS - and manually verifying that every control is announced correctly, every state change is exposed, and every interaction is reachable by keyboard. It's slower, it requires platform-specific expertise your web QA process probably doesn't have, and it can't be bolted onto an existing web accessibility audit checklist.

A checklist for software vendors

• Confirm your UI toolkit either uses native OS controls or explicitly implements the platform accessibility API (UIA / NSAccessibility / AT-SPI) for every custom control.
• Test with the platform's real assistive technology, not a web accessibility scanner - there is no DOM equivalent to scan.
• Walk the entire application by keyboard only, including menus, dialogs, and any custom-drawn widgets (canvases, grids, drag-and-drop panels).
• Test the installer and first-run experience specifically - it's commonly excluded from accessibility review and commonly fails.
• Expose error messages and dynamic status updates to assistive technology as they occur, matching the intent of live-region patterns on the web.
• Verify compatibility with OS-level screen magnification and voice control, not just screen readers.
• Track EN 301 549 v4.1.1 as it moves toward publication in 2026 - expect the WCAG 2.2 baseline to extend into future guidance for software as it has for the web.

Mobile and web accessibility audits are now a routine line item for most EAA compliance programmes. Desktop software audits usually aren't - not because the obligation is smaller, but because the testing methodology looks unfamiliar to teams whose accessibility expertise was built entirely around the browser.