Gatsby route changes focus the router wrapper instead of main content, breaking skip-link expectations

Symptom

In a Gatsby site, navigating between pages moves keyboard focus to the router's wrapper element rather than to the main content region. For screen reader and keyboard-only users, this means a skip-navigation link that targets <main> behaves inconsistently: after a client-side route change, focus sits on the wrapper, and the next Tab press or skip-link activation does not land where users expect.

Context

Gatsby uses @reach/router internally, and its documented accessibility behavior is to programmatically focus a wrapper div (with tabindex="-1") on route change so page transitions are announced. Navigation uses gatsby-link, so this focus management is active. The site also provides a standard skip link pointing at the main content landmark.

The tension is that the default focus target (the wrapper) and the skip link target (main content) are different elements, so the two accessibility mechanisms can work against each other. Behavior may also differ across Gatsby versions (v2 through v5), so any approach needs to be verified against the version in use and tested with NVDA and VoiceOver.

Questions

• Is there a supported way in Gatsby to make route-change focus land on the main content region (or another chosen element) instead of the router wrapper?
• Should the skip link be repointed to the router wrapper, or should focus management be customized so both mechanisms agree on one target?
• Does the recommended approach differ between Gatsby versions, and how can the actual focus target be verified programmatically?