Visible focus

Silktide tests that controls on your page - links, buttons, and form fields - visibly change when selected with the keyboard. Without a visible change, keyboard users cannot tell where they are on the page.

You can try it yourself: load a page and press the Tab key repeatedly. Each control you land on should alter its appearance, for example gaining an outline or a different background color.

Every standard browser control shows focus by default, so a failure here almost always means a stylesheet has switched the default indicator off, or a custom control was built without one.

Why this matters

People who cannot use a mouse navigate with the Tab key, and the focus indicator is their only way of knowing which control they are on. When a designer removes it - often because the default outline was considered ugly - keyboard users are left pressing keys blind, with no idea what pressing Enter will activate.

How to fix it

Find where your disables focus, typically a rule like outline: none or outline: 0, and remove it.
If you replace the default outline, provide a clear alternative on the :focus state:

/* Restores a visible indicator for focused fields */
input:focus {
  outline: 2px solid #396196;
}

Give custom controls, such as your own drop-down menus or sliders, an explicit focus style - they have no default one.

For how prominent an indicator should be, see Clear focus, the stricter companion to this check.

How Silktide tests this

Simulate a keyboard user tabbing through every focusable element on the page, skipping elements you have excluded from checking, elements hidden from sighted users, and elements with a tabindex of -1.
Compare each element's styles in its focused and unfocused states.
Flag elements whose appearance does not change in any way that a sighted user could distinguish when they receive .

Troubleshooting

The focus style needs JavaScript to appear

Focus styles should be defined in CSS alone. If focus is applied by - for example a script adding a class - Silktide may not observe it, and it may not work for assistive technologies without a physical keyboard. Try disabling JavaScript and tabbing through the page to confirm.

Focus styles we cannot measure

Some ways of implementing focus cannot be detected automatically:

Focus drawn with pseudo-elements such as ::before or ::after.
Focus applied via :focus-within on a container.
Focus styles cascaded to child elements, such as a <span> inside a link. Some of these cases are detected, but not all variations.

Elements using these techniques are skipped rather than flagged.

Unexpected elements are focusable

Tags like <div> or <span> become focusable when given a tabindex of 0 or higher, which is how custom controls support keyboard use. If one appears in your results, it is genuinely reachable by keyboard and needs a focus style. See tabindex on MDN.