Name, Role, Value
For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
In plain language
Every button, link, checkbox, menu, or other control on a page must clearly say what it is (its role), what it's called (its name), and its current state (like checked, expanded, or selected) — not just visually, but to assistive technology too.
Why it matters
A screen reader can't "see" that a styled box looks like a button. It relies entirely on the underlying code to say "this is a button, named Submit, and it's currently disabled." If custom-built controls don't expose this information, screen reader users have no idea what they're interacting with, or whether their action even worked.
In practice
Fails this criterion
A custom dropdown is built entirely from styled boxes, with nothing marking it as a dropdown at all. When a screen reader user reaches it, they hear nothing — that part of the page seems to go silent, with no clue what it is or how to open it.
Meets this criterion
The same dropdown is built so a screen reader announces "Country, dropdown, collapsed" the moment it's reached. The user immediately knows where they are, what it is, and that they can open it — and hears an update the moment it expands.
Test it yourself
Turn on a screen reader (VoiceOver, NVDA, or similar) and tab through every interactive element on the page. For each one, you should hear what it is, its name, and its state. If a control is silent, or only announced as "clickable" with no name, this criterion is failing.