Consumer computing

What the EAA covers here

This sector covers consumer general-purpose computing hardware and the operating system it ships with, treated as one product. That pairing is deliberate: a computer’s accessibility isn’t really a hardware question or a software question in isolation, it’s whether the machine a consumer buys off the shelf can be set up and used by someone relying on a screen reader, magnification, alternative input, or captioning from the first boot onward.

Business and specialist workstations sold only through enterprise channels sit outside what this page is about; the target here is the general-purpose consumer machine.

The computer and the operating system together

Hardware contributes the physical side of this: ports and connectors that support standard assistive-technology peripherals, and controls (volume, brightness, power) that don’t depend on fine motor precision or vision alone to operate. The operating system contributes the software side: a built-in screen reader, magnifier, and captioning support that exist out of the box rather than requiring a separate purchase, and an accessibility API that other software — including software the manufacturer didn’t write — can rely on to stay compatible.

Built-in accessibility features

The requirements here reach further than “the OS has an accessibility menu somewhere.” They cover whether third-party and bundled software can actually use the platform’s accessibility services rather than drawing its own inaccessible controls, whether a system update can silently reset or disable a user’s accessibility preferences, and whether the user’s chosen settings persist the way any other preference would. A feature that exists but gets wiped by the next update hasn’t really shipped.

What auditors look at first

A review usually starts at first setup: how many steps it takes to reach and turn on a core accessibility feature, and whether that path is itself accessible to someone who hasn’t turned anything on yet. From there it checks whether commonly bundled applications expose their interface correctly through the OS’s accessibility API rather than silently failing, whether an update preserves accessibility preferences across the upgrade, and whether the product’s own documentation actually names the accessibility and compatibility features it ships with, rather than leaving them undocumented.