In a component test, what does asserting a control's exact accessible name — for example with jest-dom's toHaveAccessibleName — give you that a rule-based axe run does not?

## Presence versus identity The rules an accessibility engine can automate for naming all have the same shape: does this element end up with a non-empty accessible name? That question is decidable from the markup, so it automates cleanly — and it stops at exactly the point where the interesting failures begin. All of these pass a naming rule: ```html <button aria-label="button">×</button> <button aria-label="Submit form">Save</button> <button aria-label="Delete">Archive</button> ``` The first is meaningless, the second contradicts the visible label, the third is actively wrong. The engine sees three non-empty strings and reports no violation. An assertion on the *value* of the name is what separates "has a name" from "has the right name". ## Why the name is user-facing text It helps to argue this the way you would argue for asserting on visible copy. The accessible name is what a screen reader announces when the control receives focus. It is also what voice-control software matches when a user says "click Save" — which is why a mismatch between the visible label and the computed name does not merely confuse, it removes the ability to operate the control by voice at all. Treating that string as untested implementation detail is the same mistake as never asserting on button text. And because the name is *computed* from several possible sources rather than read from one attribute, it is unusually easy to change by accident. Adding an attribute, wrapping the content, hiding an inner element, or moving text into an icon can all change the announced string while the visible rendering looks identical — and a rule check stays green through every one of them. ## What the assertion looks like The jest-dom family provides matchers for this directly: ```js render(<IconButton icon="trash" label="Delete item" />); expect(screen.getByRole('button')).toHaveAccessibleName('Delete item'); ``` There is a companion for descriptive text — `toHaveAccessibleDescription` — which is the assertion to reach for when a field has a permanent format hint or a validation message wired to it: it checks that the supporting text actually reaches the control rather than merely sitting near it visually. ## When it is redundant, and when it earns its place Be honest about the overlap. If the test already finds the element by role *and* name, the name has effectively been asserted — a wrong name means the query finds nothing and the test fails on its own. Adding a separate matcher immediately afterwards is duplication. The explicit assertion earns its place when: - The element is obtained some other way — it is the only control of its kind, it came from a container-scoped lookup, or the test is checking a control it did not need to interact with. - The name is the thing under test. A component whose whole job is composing a label from an icon plus a prop plus fallback text deserves a test per branch, and reading a list of expected names in one place documents the contract better than the same strings scattered through queries. - The name is computed from multiple sources and you want a regression guard on the precedence outcome, without asserting on any particular attribute. - It is a shared component. A name that is wrong once in a leaf screen is a bug; a name that is wrong in a library component is the same bug on every screen that consumes it. ## What it still does not buy you Two limits are worth stating out loud, because interviewers listen for them. First, the assertion guards a decision but does not make one. Whether the control should be called "Save", "Submit form" or "Save draft" is a copy and usability judgment; the test only ensures the chosen answer stops silently drifting. Second, a correct name says nothing about whether the control is operable, reachable, focus-visible, or announced at a useful moment. Naming is one property among many, and a component with perfect names can still be unusable by keyboard. ## The reusable principle The generalisation is worth keeping past this specific matcher: automated rules verify that a required property *exists*; tests verify that it has the *value* your product promised. Wherever a rule engine checks presence, ask whether the value is user-facing — and if it is, assert on it the way you would assert on any other visible copy.