Keyboard navigation gets stuck

Two different problems that feel identical#

The distinction matters because a focus indicator can be defined, look entirely valid in the stylesheet, and compute to nothing on the live element. That has happened here, and it is why checking the source is not how you confirm a focus ring exists — reading the computed value on the focused element is.

Causes, most likely first#

1. No visible focus indicator on that control. Focus is moving; the ring is not being drawn. With 56 ordered stylesheet layers, an outline set in one layer can be removed by another that names the same thing.
2. Focus is on something scrolled out of view. The control has focus, the page has not scrolled to it, and Tab appears to do nothing because nothing visible changes.
3. Focus is on something covered. An overlay or a stack of notifications sits above the focused element, so it responds to the keyboard while looking inert.
4. An overlay has kept focus after closing visually. The panel is gone from the screen and the region it created is still holding the tab order.
5. A genuine trap. Focus cycles inside a region and no key releases it. This is the rarest of the five and the only one that is unambiguously a defect in the tab order itself.

What Connect completed#

The page rendered, its data is correct, and any work you saved before the keyboard stopped cooperating is saved — a form that reached the server is recorded whatever happens to the focus afterwards. Every visible element carries a data-ui name, so the control involved can be identified precisely once you can say which one it was.

What Connect did not complete#

It did not return you to where you were: a reload clears the trap and also clears your position, so anything typed and not submitted is gone. There is no keyboard shortcut that forces focus back to the start of the page, and no in-product way to report the problem from the screen where it happens. Connect claims no accessibility certification, and this page does not imply one.

What you can do#

1. Press Escape once.

   Result If an overlay was holding the tab order, this releases it and everything works again — the cheapest test, and often the answer.

2. Move focus out of the page into the browser's own controls — on most desktop browsers, the address-bar shortcut or the key that cycles browser panes — then shift-tab back in.

   Result Focus re-enters the document from the edge, which routes around a region that was holding it.

3. If neither works, reload.

   Result This always clears it, at the cost of anything unsent. Submit or copy unsaved text first if you can reach the control to do so.

4. Write down the route, the control's data-ui name if you can see it, the viewport width and whether an overlay was open.

   Result Those four are what let somebody else reproduce it. 'Tab stopped working' on its own is not reproducible by anyone.

What an administrator can do#

• Confirm which of the two problems it is by reading the computed outline on the focused element, not the stylesheet. A ring that is defined and computes to nothing looks correct in every file you would open.
• Walk the tab order at the width that was reported. Order and reachability both change with layout, so a trap at one width may not exist at another.
• Check whether the region still exists after its overlay is closed. A panel that is visually gone can still own the focus order.

When to escalate#

Escalate whenever a task cannot be completed with the keyboard alone, and say which task — 'approve a held reply' is actionable, 'keyboard navigation is broken' is not. Escalate immediately for a genuine trap that Escape does not release, since that is the one case where the only way out is to abandon whatever the person was doing.

Questions#

Related#

• A focus ring that was defined, valid-looking and computed to nothing
• The layout is wrong on a phone
• Defects that are invisible in the source and obvious in a browser
• A screen is empty and should not be
• Troubleshooting
• Account and access