Glossary · Accessibility term
User agent
A user agent is any software that retrieves and presents web content, which takes in browsers, media players, plug-ins, and assistive technology as well. Assistive technology arrives by either of two routes. It can act as a user agent in its own right, the way a self-voicing browser does, or it can work alongside a mainstream one, the way a screen reader usually works with Chrome. The category matters because WCAG splits the duties. Your job is the content and the user agent's job is presenting it, which is why several rules are met by not interfering rather than by adding anything at all. Zoom is the clearest case. The browser already does it, and your responsibility is not to prevent it.
In practice
Before you add anything, check whether the browser already does it. Zoom and text resizing both work by default until something on your side overrides them, and W3C says as much in its own words. Scaling content is primarily the user agent's job, and the author's responsibility is to write content that does not stop it happening. Where the browser or the platform draws a control itself, some criteria carve that case out by name, and the exception is written into those particular criteria rather than granted across the standard. Find the wording before you rely on it, and check nothing in your code has changed what the platform drew.
When a rule asks for a mechanism, the user agent may be the thing providing it. WCAG lets a mechanism come from the platform or the user agent rather than from anything you built, which is why supporting a password manager counts as helping somebody through a login. One criterion writes the split into its own text, excusing a dragging movement where the behavior belongs to the user agent and the author has not modified it.
The two halves of the split are not equally settled, and that is the honest limit on the argument. WCAG binds content authors and is a full W3C Recommendation. So is the first version of the matching standard for user agents, from 2002, and the second version stalled and remains a Working Group Note, so the guidance browsers are actually built against today is more than twenty years old. The split does not disappear off the web so much as move. In desktop and mobile software the application is often both the content and the thing presenting it, and W3C's own note on applying WCAG outside the web works through where the platform still counts as a separate provider. So the question a native app raises under EN 301 549 or Section 508 is which part of the platform is doing the job, not whether the split exists.
Why it matters
The failures this term explains are the ones where nothing was added and something working was removed. The browser was handling it correctly. The site intervened. That makes it the fastest sanity check available on any rule that sounds like extra work. Ask what the browser already does. Then ask what your code does to it.
A feature somebody tried to switch off
Putting user-scalable=no in a viewport tag is an attempt to take pinch zoom away from a reader who needs it. Nothing was added, and something the browser was doing correctly was removed. It does not even work everywhere any more, because Safari on iOS has ignored that declaration by default since iOS 10 and browser settings elsewhere can ignore it too. An app embedding a web view is configured separately and can still honour it, and so can other engines. And writing it still says exactly what you meant to do.
Where this shows up on the site
Related terms
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.