Skip to main content
Accessibility.com, LLC
Category: Assistive Technologies

Assistive Technology

Also known as: AT, assistive technology device, adaptive technology
Simply put

Assistive technology (AT) refers to any device, equipment, software, or product system that helps people with disabilities perform tasks they might otherwise find difficult. These tools support individuals in overcoming physical, sensory, cognitive, or learning barriers. Examples range from off-the-shelf products to specialized or customized systems.

Formal definition

Assistive technology (AT) is commonly defined as any item, piece of equipment, software program, or product system, whether acquired commercially off the shelf, modified, or customized, that is used to increase, maintain, or improve the functional capabilities of individuals with disabilities. In a digital accessibility context, AT encompasses hardware and software that mediate between a user and content or interfaces, addressing physical, sensory, cognitive, or learning barriers. This definition, as reflected in federal descriptions cited in the evidence, is broad and functional rather than prescribing a specific list of technologies. Note that this entry describes the general concept of AT; it does not constitute legal advice, and the applicability of particular statutory or regulatory definitions may vary by jurisdiction and context.

Why it matters

Assistive technology is central to how many people with disabilities access digital content, physical environments, and everyday tasks. Because the definition is broad and functional rather than a fixed list of products, it captures everything from off-the-shelf tools to highly customized systems. For organizations working toward digital accessibility, understanding AT matters because content and interfaces must work with the tools people actually rely on to increase, maintain, or improve their functional capabilities.

From a compliance and design standpoint, the significance of AT is that accessibility is not achieved in the abstract but in the interaction between a user, their assistive technology, and your content. A page that appears usable to a sighted mouse user may present significant barriers to someone relying on AT to mediate a sensory or physical barrier. This is why conformance with technical standards, while important, does not by itself guarantee a usable experience, and why testing with actual assistive technology is generally regarded as necessary alongside automated checks.

This entry describes the general concept of assistive technology and is not legal advice. Statutory and regulatory definitions of AT may vary by jurisdiction and context, and requirements evolve through regulation and case law. Organizations should consult qualified legal counsel and current agency guidance when assessing specific obligations.

Who it's relevant to

Accessibility engineers and QA testers
Those building and validating digital products need to understand how assistive technology interacts with their code, because meeting technical success criteria does not guarantee that content functions correctly with the tools people use. Manual and assistive-technology testing is generally required to catch issues that automated tools cannot detect.
UX and product designers
Designers benefit from understanding that AT mediates the user's experience of an interface. Because the same content may be accessed through many different tools addressing physical, sensory, cognitive, or learning barriers, designs should aim to be robust and adaptable rather than tuned to any single technology.
Compliance officers and business leaders
Leaders responsible for accessibility programs should recognize that accessibility is realized in the interaction between users, their assistive technology, and an organization's content. This informs how testing, procurement, and remediation are scoped. This is not legal advice, and applicable obligations may vary by jurisdiction and context.
Legal counsel
Counsel assessing accessibility obligations should note that statutory and regulatory definitions of assistive technology can vary and that the concept described here is functional and broad. Specific requirements evolve through regulation and case law, so current agency guidance and jurisdiction-specific analysis are advisable.
People with disabilities who use AT
Individuals who rely on assistive technology to overcome physical, sensory, cognitive, or learning barriers are the primary users whose functional capabilities these tools are meant to increase, maintain, or improve, and whose real-world use determines whether content is genuinely accessible.

Inside AT

Screen Readers
Software that converts on-screen text and interface elements into synthesized speech or braille output, enabling users who are blind or have low vision to navigate and interact with digital content. Common examples include JAWS, NVDA, and VoiceOver.
Screen Magnification Software
Tools that enlarge portions of the screen and may adjust contrast or color to assist users with low vision, allowing them to perceive content that would otherwise be difficult to read at default sizes.
Alternative Input Devices
Hardware and software that replace or supplement standard keyboard and mouse input, such as switch devices, sip-and-puff systems, eye-tracking systems, and head pointers, supporting users with limited or no fine motor control.
Speech Recognition Software
Applications that allow users to control a device and enter text through voice commands, commonly used by people with motor disabilities or those who cannot use a keyboard efficiently.
Braille Displays
Refreshable hardware devices that render digital text as tactile braille characters, often working in conjunction with a screen reader for users who are deafblind or who prefer tactile output.
Captioning and Transcript Tools
Technologies that present audio content as synchronized text (captions) or as separate text documents (transcripts), supporting users who are deaf or hard of hearing.
Alternative and Augmentative Communication (AAC) Devices
Tools that help users with speech or language disabilities communicate, ranging from symbol boards to speech-generating software and devices.

Common questions

Answers to the questions practitioners most commonly ask about AT.

Does assistive technology only refer to screen readers?
No. Screen readers are one widely known category of assistive technology, but the term is much broader. Assistive technology encompasses any hardware or software that helps people with disabilities perform tasks they might otherwise find difficult. This includes screen magnifiers, screen readers, braille displays, alternative input devices such as switch controls and eye-tracking systems, speech recognition software, text-to-speech tools, captioning tools, and cognitive supports. Treating assistive technology as synonymous with screen readers can lead teams to overlook the needs of users who rely on other tools.
If a website meets WCAG success criteria, does that guarantee it works well with assistive technology?
Not necessarily. Meeting WCAG success criteria and passing automated checks addresses only a portion of what determines a usable experience with assistive technology. Automated testing detects a limited subset of issues, and conformance does not guarantee that real users of screen readers, magnifiers, or other tools will have a smooth experience. Manual testing and testing with actual assistive technology are generally required to identify problems that automated tools and conformance checklists miss. Conformance is also distinct from legal compliance, which can depend on regulation and case law.
How should teams test their products with assistive technology?
Testing generally combines automated tools with manual evaluation and hands-on testing using real assistive technology. Because automated tools catch only some issues, teams often test with commonly used screen readers, keyboard-only navigation, screen magnification, and voice input across the browsers and platforms their users rely on. Involving people who use assistive technology in their daily lives can surface usability problems that internal testing may not reveal. The specific combination should reflect the platforms and tools relevant to a given product's audience.
Which assistive technologies should a team prioritize when resources are limited?
Prioritization commonly reflects the platforms and user base a product serves, since assistive technology usage varies by operating system, browser, and context. Many teams begin with keyboard operability, which underpins support for a range of assistive technologies, and then test with widely used screen readers on the relevant platforms. Because needs differ across audiences, it is generally advisable to base priorities on data about actual users where available rather than assuming a single tool represents all users.
What is the relationship between assistive technology and semantic HTML or ARIA?
Assistive technology relies heavily on the underlying structure and semantics of content to convey meaning to users. Correct, semantic HTML generally provides the most reliable foundation, because native elements expose roles, states, and properties that assistive technologies interpret. ARIA can supplement HTML to describe custom components, but it is intended to fill gaps rather than replace native semantics, and incorrect use can create barriers. Building on solid semantic structure typically improves how assistive technology presents and operates content.
Does supporting assistive technology mean building separate features or a separate site?
Generally not. The prevailing approach is to build a single, accessible experience that works with assistive technology rather than maintaining separate accessible versions, which can become outdated and provide an unequal experience. Designing with accessibility in mind from the outset tends to be more sustainable than retrofitting or creating parallel content. This entry is informational and not legal advice; requirements can vary by jurisdiction and evolve through regulation and case law, so consult qualified counsel for questions about specific obligations.

Common misconceptions

If content passes automated accessibility checks, it will work well with assistive technology.
Automated testing detects only a portion of accessibility issues. Ensuring content functions correctly with assistive technology generally requires manual testing and hands-on evaluation with actual tools such as screen readers, because many barriers only surface during real interaction.
Assistive technology refers only to screen readers.
Screen readers are one widely known example, but assistive technology encompasses a broad range of hardware and software, including magnifiers, alternative input devices, speech recognition, braille displays, and captioning tools that serve users with varied disabilities.
Meeting technical guidelines such as WCAG guarantees a good experience for assistive technology users.
Conformance with success criteria is distinct from usability. Content can satisfy technical requirements yet still present a difficult or confusing experience when used with assistive technology, which is why testing with real users and tools is commonly recommended.

Best practices

Test digital content with multiple assistive technologies, including at least one screen reader, rather than relying solely on automated scanning tools.
Include people who use assistive technology in usability testing to identify barriers that conformance checks may miss.
Verify that interactive elements are operable through the keyboard and alternative input devices, not just the mouse.
Ensure text alternatives, captions, and transcripts are provided so that content is available across screen readers, braille displays, and captioning tools.
Treat conformance with technical guidelines as a baseline and confirm the actual experience works for assistive technology users, since passing criteria does not guarantee usability.
Document which assistive technologies and versions were tested, and re-test periodically as both content and assistive technologies evolve.