Assistive technology
Umbrella term for the tools people use to operate a computer differently: screen readers, magnifiers, switches, voice control, braille.
See it
What it is
Assistive technology is the umbrella over everything people use to operate a computer differently: screen readers (NVDA and JAWS on Windows, VoiceOver on Apple, TalkBack on Android), screen magnifiers, refreshable braille displays, switch access, voice control like Dragon or Apple's Voice Control, eye tracking, and alternative keyboards. Note the acronym: people write AT constantly and rarely expand it.
The reason one set of habits serves most of them is the accessibility tree, the parallel structure the browser builds from your markup and hands to anything that asks for it. Screen readers, braille displays, and voice control live off that tree. Magnifiers and alternative input devices largely do not: a magnifier is enlarging pixels and a switch is walking focus, so they care about layout, zoom, and focus order instead. Real buttons, labelled inputs, ordered headings, and landmarks feed the tree correctly, so semantic HTML pays off across most of the category at once. A custom div-based widget does still show up in the tree, just as a generic node with no role, no name, and no state, which is the same as useless and has to be rebuilt with ARIA by hand.
Gotcha: AT is not one behavior, and fixing for one can break another. Stuffing a clever aria-label onto a button whose visible text says something else makes it unreachable by voice control, because the user says what they can see. People also mix AT with ordinary input: a magnifier user still drives a mouse. And testing only in Safari plus VoiceOver misses the majority of real users, who are on Windows with NVDA or JAWS.
Ask AI for it
Review this component so it works with assistive technology, not just with a mouse. Replace div and span controls with real button, a, and input elements, and keep those native semantics rather than layering roles on top of them. Give every control an accessible name whose text starts with its visible label (so voice control users can say it). Make the whole thing keyboard operable with a visible focus indicator. Add only the states the widget genuinely has: aria-expanded on something that expands, aria-selected inside a real selection widget, aria-current on the current item. Announce async updates in a polite live region. Then write four separate test procedures I can actually run: a screen reader pass naming one browser and reader pairing, a voice control pass listing the phrases that must work, a keyboard-only pass listing every key and its expected result, and a 400% zoom pass. Give the steps and the expected result for each, not a prediction of what the software will say.