skip to content

When a control's accessible name disappears and a self-repairing suite substitutes a positional locator, what defect goes unreported?

level: seniorimportance: nice to knowfreq 22%

answer

  1. Some anchors are also product contracts
  2. Who cannot use position to find a control
  3. Here the break is itself the finding
  4. Name loss must fail, never be substituted

basics

~20 s

An accessibility regression. The control no longer exposes a name assistive technology can announce, so some users cannot reach it - and the repair that routed around the missing name turned the one automated signal for it into a pass.

solid answer

~50 s

The accessible name is what the platform hands to a screen reader, to voice control and to other assistive technology: it is how someone who cannot see the layout identifies and addresses a control. When it disappears - an icon-only button ships without a label, the text moves into a decorative wrapper, a generated identifier replaces the words - that control becomes unaddressable for those users. That is a shipped defect. A repairing suite hides it twice over: it cannot find the control by name, so it falls back to shape and position, drives it successfully, and reports green. **Position is precisely the property those users do not have.** So the one failure mode where the anchor breaking *is* the defect is the one an adaptive suite is best at absorbing. Name loss should fail, never heal.

code

pseudocode · 11 lines
pseudocode
resolve(step):
    element = find_by_announced_name(step.expected_name)
    if element exists:
        return element

    if step.anchor_kind == ANNOUNCED_NAME:
        # the missing name is the finding - do not substitute
        fail(category = ACCESSIBILITY_REGRESSION,
             detail   = "no control announces " + step.expected_name)

    return substitute(step)   # other anchor kinds may be repaired

go deeper

for a junior

Know what an accessible name is: the text a platform exposes so assistive technology can announce and address a control. Be able to say why an icon with no label has none.

for a middle

Explain why falling back to position hides this specifically - position is the property the affected users lack, so the substitution succeeds through the channel that is not broken.

for a senior

Show that you would exclude name-resolution failures from repair and treat them as product defects with a named owner. Interviewers want you to recognise the one break that is itself the finding.

for a principal

Own the policy: decide which product contracts a suite may route around at all, and be able to defend adaptive lookup elsewhere while refusing it on this one.

## What an accessible name is, and who depends on it Every interactive control has - or should have - a **name that the platform exposes to software other than the visual renderer**: the string a screen reader announces when focus lands on it, the phrase a voice-control user speaks to activate it, the label a switch-access or automation tool uses to address it. It normally comes from the visible text, and where there is no visible text, as on an icon-only control, it has to be supplied explicitly. That name is not decoration and it is not a testing convenience. For a user who cannot see the layout it *is* the control's identity. Position, size, colour and proximity are unavailable to them; the name is the whole addressing scheme. If it disappears, the control is still on screen and still clickable with a pointer, and it has become unreachable for everyone who navigates by name. Names vanish in unremarkable, well-intentioned ways. A labelled button becomes an icon during a visual refresh. The text moves into a decorative wrapper the platform no longer associates with the control. A component is rewritten and the label is passed as a hover tooltip instead. A generated identifier replaces the words. From the outside, none of these look like breakage. ## Why an adaptive suite is uniquely bad at reporting this Compare what three kinds of suite do when the name vanishes from a control whose case anchors on it. | Suite behaviour | What happens when the name is gone | What the team learns | | --- | --- | --- | | Anchors on the announced name, never repairs | lookup fails, case fails | a control lost its name - accurate and immediate | | Anchors on the announced name, repairs on failure | falls back to shape and position, case passes | nothing | | Anchors on a dedicated test attribute | passes throughout | nothing, and it never had a chance to notice | The middle row is the trap, and it is the one an adaptive suite occupies by design. A name-based lookup that fails is, in this one situation, not a test problem at all: **the break is the finding**. It is the closest thing most suites have to a free, continuous accessibility check, and it fires as a side effect of how the case locates things rather than as extra work anyone had to fund. Now look at what the repair falls back to. Similarity scoring leans on position, shape, surrounding text and structural neighbourhood - precisely the properties a sighted pointer user has and an assistive-technology user does not. The substitution succeeds *because* it uses the channel that is not broken, and then reports success about the channel that is. That is not a near miss; it is an inversion. The one failure mode where the anchor breaking is itself the defect is the one the mechanism is best at suppressing. ## What to do about it - **Exclude name-resolution failures from repair.** When the anchor kind is the announced name and no element carries it, fail. No confidence value earns a substitution here, because the missing name is the thing you wanted to know. - **Attribute it to the product, not to the suite.** The finding is *this control no longer exposes a name*, which belongs to whoever owns the component, not to whoever maintains the case. - **Assert the name separately from how the case finds the element.** A case that locates a control by a dedicated attribute can still assert that the control announces the expected name. That decouples the check from the lookup strategy, so the signal survives however the suite chooses to find things. - **Distinguish a loss from a pre-existing absence.** A control that never had a name and was always anchored by position was never covered. That is a gap rather than a regression, and it is found by a deliberate sweep, not by waiting for something to break. - **Do not confuse it with coverage.** A name-resolution failure catches one class of accessibility regression on the controls your cases happen to touch. Focus order, contrast, announced state, keyboard traps and everything else are untouched by it. ## The judgement being tested An interviewer asking this is checking whether you can tell an anchor from a contract. Most anchors are incidental: a structural path, a hashed class, a proximity rule. They exist so a machine can find something, and substituting one for another when it breaks is a reasonable engineering trade. The announced name is different in kind. It exists because a person has to find something, and the suite is merely borrowing it. Repairing around it converts a user-facing failure into a machine-facing convenience, and the run reports green while the product has genuinely regressed for a group of people who will not be in the room to say so.

  • An icon-only control has never had a name, and the case has always anchored on position. What does that tell you?
    That the defect predates the suite and was never reported, because there was no name-based lookup to break. An adaptive suite masks new losses; a case that anchored on position from the start masked the original one. Covering it needs a direct assertion that the control exposes the expected name, run independently of how the case locates it.
  • Why is "the case passed, so the control is reachable" wrong here?
    Because the runner reaches elements through the platform's element tree with full knowledge of position and structure, which is not the interface an assistive-technology user has. Reachability for the runner and reachability for that user are different properties, and only one of them was exercised. A pass says the flow can be driven, never that it can be driven by everyone.

It is an inspector reporting a lift in order after the floor labels were removed, because he already knew which button to press.

saying these in an interview costs you the question

  • Calls a missing accessible name a locator problem, not a defect
  • Says a passing case proves the control is reachable for everyone
  • Accepts icon-only controls because pointer users manage fine
  • Lets the suite substitute position whenever the name is gone
  • Assumes a separate audit will catch it later anyway