skip to content

Why is removing a control's default keyboard-focus indicator, with no replacement, a conformance failure rather than a styling choice?

level: middleimportance: should knowfreq 52%

answer

  1. Someone has to see where they are
  2. A pointer is not the only input
  3. Removal without replacement is the defect
  4. It must stand out from its surroundings
  5. Every focusable control, on every surface

basics

~20 s

A keyboard user's only clue to where they are is the focus indicator; strip it and the interface becomes unusable without a pointer. Success criterion 2.4.7 Focus Visible, level AA, requires one, so removal with no replacement is a defect.

solid answer

~50 s

Every keyboard, switch and voice user drives an interface by moving the focus point from one control to the next, and the **focus indicator** is the only feedback telling them where that point now sits. Success criterion **2.4.7 Focus Visible**, level AA, requires that any keyboard-operable interface has a mode of operation in which the keyboard focus indicator is visible, so a theme that suppresses the platform default and puts nothing back fails outright, whatever the visual rationale. A replacement is entirely allowed, and is often better than the default - but it has to be genuinely perceivable. **1.4.11 Non-text Contrast**, also level AA, covers the visual information needed to identify a control's state, which means the indicator must stand out against what sits beside it rather than being a faint tint shift. It also has to appear on *every* focusable control, including those a pointer never visits.

code

pseudocode · 11 lines
pseudocode
FOCUS PASS  (run by hand, pointer untouched)

  1. put focus on the first control of the screen
  2. move focus forward, one control at a time, to the end
  3. at every stop, name the control you can see is focused
  4. repeat on the lightest surface and on the darkest one

  FAIL if: nothing visibly changed
           the change is a faint tint you had to hunt for
           the focused control sits under a pinned bar
           focus appears to vanish for one or more stops

go deeper

for a junior

Be ready to say that keyboard focus is the point receiving keyboard input, that the indicator is how a user knows where it is, and that a named requirement asks for it to be visible. Never suppress it without putting something back.

for a middle

Explain the mechanics: the requirement is visibility rather than a fixed appearance, a replacement must be perceivable against adjacent colors and on every surface, and it must reach every focusable control including custom widgets built after the theme.

for a senior

Demonstrate the habit of running a keyboard-only focus pass across light and dark surfaces, and be able to name the failure modes that static design review never catches - vanishing focus, faded indicators, and controls hidden under pinned furniture.

for a principal

Own the position that the indicator is part of the product's interaction contract, not its decoration. Give the design team a real brief for a replacement so the choice is which indicator to ship, never whether to ship one.

## Focus is a location, and somebody has to see it **Keyboard focus** is the single point on a screen that receives input from the keyboard. Exactly one control holds it at a time, and moving it is how a large group of people operate software: keyboard users, people using a switch or a head pointer, people driving the screen by voice, people whose tremor or pain makes a pointer unreliable, and people who simply type faster than they aim. For all of them, the **focus indicator** plays the role a pointer plays for everyone else. It answers the only question that matters before pressing a key: *where am I?* An interface with no visible indicator is not merely less pretty for that user; it is a screen that has to be operated blind, counting movements and hoping. That is why removing it is not a styling decision. Styling decisions trade one appearance for another. This one removes a whole input method. ## What the standard actually requires **2.4.7 Focus Visible**, at level AA, requires that any keyboard-operable interface has a **mode of operation** in which the keyboard focus indicator is visible. Two things follow from that wording: 1. It is about *visibility*, not about a particular look. A custom indicator that is clearly perceivable satisfies it. There is no mandated shape, color or thickness. 2. It says *a mode of operation*, which is why showing the indicator when input arrives from a keyboard and not immediately after a pointer press is an accepted pattern rather than a violation - as long as every keyboard, switch and voice user still gets it on every focusable control. Two further requirements shape what a replacement has to be: - **1.4.11 Non-text Contrast**, level AA, covers the visual information needed to identify user interface components and their states. A focus indicator is exactly that, so a change the user cannot pick out from the adjacent colors is not really an indicator. - The indicator has to be present on **every** focusable control, including custom widgets, controls inside scrolling areas, and controls a pointer user would never visit deliberately. ## What a replacement has to do 1. **Be perceivable against its surroundings.** A one-shade tint change on a busy surface is not an indicator, however deliberate it looks in a design file. 2. **Be perceivable on every surface the control can sit on.** A pale ring works on a dark bar and disappears on a light card. 3. **Not depend on color alone.** A ring, a thickened edge, an offset or a shift of shape survives conditions where a hue change does not. 4. **Cover every focusable control.** The commonest regression is a custom widget that never received the replacement because it was built after the theme was written. 5. **Stay on screen.** An indicator that is technically drawn but sits underneath a pinned bar or an overlay is not doing its job. ## Where teams lose it | Move | Why it looks reasonable | What it actually costs | | --- | --- | --- | | Suppress the default product-wide, plan to restyle later | The default clashes with the visual language | The restyle rarely lands, and the product ships unusable without a pointer | | Replace it with a faint tint change | Subtle feels premium | The indicator exists but cannot be found on a dense screen | | Style only the controls in the design review | Those are the visible ones | Custom widgets and controls in scroll areas keep the suppressed style | | Show it for a moment, then fade it out | Reduces visual noise | The user who needs it most has already lost their place | | Reuse the selected-state treatment as the focus treatment | One treatment is simpler | Selected and focused are different states and the user cannot tell them apart | ## The habit that catches all of it Run a **focus pass** by hand, without touching a pointer: move focus forward through every control on the screen and, at each stop, say out loud which control is focused. Do it on the lightest surface and the darkest one. If at any point you cannot answer, or focus appears to vanish, that is the defect - and it is a defect a design review looking at static screens will never surface, because focus does not exist in a static screen. Two things make this argument land in a real team. First, it is not a matter of taste: there is a named requirement, and *remove it and replace it with something better* fully satisfies that requirement, so the discussion is about the replacement rather than about whether to have one. Second, the cost of getting it wrong is not spread thinly across all users - it falls entirely on the group that has no alternative way to use the product at all.

  • The design team says the default indicator looks wrong on their controls. What do you offer them?
    Replace it, do not remove it. The requirement is visibility, not a particular appearance, so they are free to design an indicator that fits the visual language - provided it is clearly perceivable against every surface the control sits on, does not rely on hue alone, and is applied to every focusable control including custom widgets. Framing it as a design brief rather than a veto usually ends the argument in one meeting.
  • Is it acceptable to show the indicator only when someone is using a keyboard?
    Yes. The criterion asks for a mode of operation in which the indicator is visible, so suppressing it immediately after a pointer press and showing it when input arrives from a keyboard is an accepted pattern and a common one. The condition is that every keyboard, switch and voice user still gets it, on every focusable control, without having to do anything to turn it on.
  • A focused control scrolls underneath a pinned header. Which requirement does that break?
    The indicator itself may be perfectly good, so this is not primarily a visibility failure - it is an obstruction one, covered by the newer requirement that a focused control must not be entirely hidden by content the author added. The fix is to reserve space for pinned furniture so that moving focus scrolls the control fully clear of it, rather than to make the indicator louder.

The focus indicator is the pointer for people who do not use one. Hiding it is the same as hiding the mouse cursor and then asking someone to click accurately.

saying these in an interview costs you the question

  • Calls the focus indicator a purely visual preference
  • Suppresses it product-wide and promises to restyle later
  • Adds a faint tint change and calls that an indicator
  • Only checks focus on controls a pointer normally visits
  • Assumes a pointer is the only way anyone drives a screen
  • Reuses the selected-state treatment as the focus treatment