How can I support keyboard navigation in a single-page website?

Start by distinguishing a substantial route change from a small in-place update. For a substantial change, consider moving focus to a clear target at the start of the new view, often its main heading. That gives keyboard users a deliberate starting point rather than leaving them at a control associated with the previous view. For a small update, moving focus may be unnecessary; it can be less disruptive to keep focus on the control that initiated the change.

Treat this as a design plan to test, not a universal rule supplied by the references. MDN advises that sequential keyboard focus order should remain logical and preserve meaning and operation. [S2] The guidance does not prescribe a particular single-page route-change target or require focus to move to a heading.

Use a meaningful main heading to identify the newly displayed view, and make sure it is easy to find when someone reads or navigates the content. If your chosen focus target is that heading, verify that it actually receives focus after the view has rendered; merely displaying a heading does not show that focus was moved there.

Also update the document title when the displayed route changes, using a concise title that describes that view. MDN explains that accurate, concise, unique document titles help assistive-technology users infer a page’s purpose without first navigating its contents, and notes that significant page-state changes can be reflected in the title. [S1] A changed title supports orientation, but the cited guidance does not establish that it replaces focus management or specify an exact title format.

Assuming these are two distinct views reached through in-app navigation, write down the expected result before implementing it:

1. The user activates the Help link from Home.
2. The Help view appears, with a clear main heading such as “Help.”
3. The document title changes to a title describing Help.
4. Focus moves to the Help heading, or to another intentionally chosen target at the beginning of the view.
5. Pressing Tab continues through Help content and controls in a sensible order.

If the change is only a small update within Home, decide whether retaining focus on the initiating control better preserves the user’s place. Check that the resulting view’s heading, title, and focus behavior agree. The title and logical-order points follow the cited MDN guidance; the specific sequence and target above are an illustrative plan, not a source-mandated implementation.

Test both paths separately: navigate to Help from within the site, then load the Help route directly. For each path, use only the keyboard: activate the navigation control when applicable, note where focus ends up, and press Tab repeatedly to see whether focus proceeds through the new view in a meaningful order. Confirm that the visible main heading and document title identify the view. If direct loading produces different focus behavior, decide what starting position is least confusing and test that case too.

Keep a short record of the expected and observed results for each route. These checks help reveal problems in your implementation, but the cited guidance does not establish a complete conformance test or guarantee accessibility. If behavior varies across browsers or assistive technologies, investigate it in your project’s actual supported environments rather than assuming one check covers all users.