A screen can appear complete while leaving its keyboard behavior undefined. The design file shows a focused input and an open menu, but it may not explain how focus reached that input, what opens the menu, or where focus goes after the menu closes. These gaps become visible when someone tries to use the interface without a pointer.
A keyboard review does not replace an accessibility audit. It gives a product team a concrete way to find interaction decisions that still need to be made. Choose a real task, such as saving a reference to a folder, and trace it from the entry point to the confirmation.
Start with the ordinary controls
Move through the page using the keyboard and note the order in which controls receive focus. Ask whether that order follows the content's meaning, whether the focused control is visible, and whether its label explains its purpose. Include controls that appear only on hover in the visual design; they still need an intentional interaction route.
Use the right control for the action. A destination should be represented by a link. An operation such as saving or opening a dialog should use a button. Native controls provide familiar behavior that custom elements need to reproduce deliberately. The W3C keyboard interface guidance is a useful reference when reviewing focus movement and composite widgets.
Follow focus into temporary surfaces
For each dialog, popover, or menu, record the control that opens it and the first relevant interaction inside. Decide how it closes and where the person returns. A design that looks clear with a mouse can become confusing if closing a dialog leaves focus somewhere unrelated to the work.
Do not assume every temporary surface should behave identically. A modal dialog, a navigation menu, and a tooltip have different purposes. Refer to the appropriate interaction pattern rather than copying keyboard behavior from whichever component was easiest to find.
Review changes that happen after an action
Saving an item may update a counter, replace a button label, or show a brief message. Consider how someone who is not watching that part of the screen will learn what happened. The interface should provide useful confirmation without moving focus unnecessarily or repeatedly interrupting the task.
Test a failed action as well as a successful one. If creating a folder fails, can the person reach the explanation and retry without reentering everything? If the item they were using disappears after deletion, which remaining control offers a sensible continuation?
Make the handoff executable
Add short behavior notes beside the visual states: opening action, focus destination, closing action, and return destination. Include an example of a complete task performed with a keyboard. These notes give implementation and review a shared sequence to check.
When studying references in Refcat, use screenshots to identify candidate patterns, then inspect the live product when access is available. A screenshot cannot prove keyboard behavior. Keep that limitation in your research notes. The strongest reference is one whose visual structure and actual interaction both support the task you need to build.