Blogs / portfolio pagination loses focus when choosing new page

[p2635]

Hi guys, I'm new to astro but this looks like San amazing theme. I'm definitely going to use this for my own portfolio. Thank you for all your hardwork.

Accessibility question: consider this scenario for blog posts .

1. Let's assume I'm in the list of blog post section with page navigation, page 1 currently selected
2. Tap page 2
3. The entire page loads and I'm back to the top of the page. I have to scroll down again to the specific blog section

Question: is this an accessibility issue? Should it jump focus automatically to the blogs section assuming I have selected a page previously?

[p2635]

Answer from Lumo AI:

Yes, this is widely considered an accessibility issue and a violation of standard web accessibility guidelines (specifically WCAG 2.1 Success Criterion 2.4.3: Focus Order).

The Problem: Loss of Context

When a user navigates to "Page 2" and the entire page reloads (or the view resets to the top), several accessibility barriers are created:

1. Disorientation for Screen Reader Users: Screen reader users rely on hearing the page title or a specific landmark to orient themselves. If the focus lands at the very top (often on the logo, navigation menu, or header), the user has no immediate indication that the content below has changed. They must manually navigate down the page to find where the new content begins.
2. Motor Impairment Burden: Users who rely on keyboard navigation (Tab key) or switch devices often cannot easily scroll large distances quickly. Forcing them to tab through the entire header, navigation, and potentially other sections just to reach the main content area creates unnecessary physical effort and time consumption.
3. Cognitive Load: Users with cognitive disabilities may lose their place in the workflow if the interface does not clearly signal where the new information is located.

The Solution: Manage Focus Programmatically

The standard best practice is to move the keyboard focus directly to the new content container immediately after the page loads or the AJAX update completes.

How it should work:

1. The user taps "Page 2".
2. The browser fetches the new content.
3. As soon as the new list of blog posts is rendered, the script moves the DOM focus to the <h1> of the blog section or the container holding the new posts (e.g., <div id="blog-posts" tabindex="-1">).
4. A screen reader announces the new heading or the start of the list, confirming the user is now looking at Page 2.

Technical Implementation Note

To achieve this without disrupting the visual experience for sighted users (who don't want to see the focus ring jump around):

• Developers typically add tabindex="-1" to the target container (the blog list). This allows it to receive focus programmatically but keeps it out of the natural Tab order.
• Upon page load/navigation, JavaScript runs element.focus().
• CSS is often used to hide the focus outline for this specific element unless the user is actively navigating via keyboard, or the focus ring is styled to be subtle.

Conclusion

While returning to the top is sometimes necessary for "Skip to Main Content" links, doing so after a pagination click is generally poor UX and an accessibility failure. The interface should preserve the user's context by jumping focus to the specific region that changed.

Recommendation: If you are the developer, implement focus management to move the cursor to the blog section header upon page load. If you are a user experiencing this, it is a valid bug to report to the site owner.

[markteekman]

Thanks @p2635 for raising this and starting the discussion! After investigating the behavior and the project’s history, I agree there are improvements to make, although I would not classify the current behavior as a definite WCAG 2.4.3 violation. There seems to be a lot more to it:

With a traditional full-page navigation, it is normal and generally accepted for focus to return to the document. However, the starter currently uses Astro’s <ClientRouter />. Although /blog/ and /blog/2/ are separate pages, the router intercepts navigation, fetches the next document and replaces the page body client-side. This makes the experience behave more like an SPA.

Astro provides a route announcer for this situation, but our paginated pages currently have the same document title and <h1>. Therefore, navigating to page 2 does not clearly communicate what changed, while focus and scroll context are also lost.

Looking through the project history, View Transitions were originally added in 2023 using Astro’s first client-side implementation. Components and starter scripts subsequently had to be adapted to Astro’s navigation lifecycle. Browser-native cross-document View Transitions for multi-page applications became available later.

The native MPA approach now appears to be a better architectural fit for this starter:

• Navigation remains a genuine document load with normal browser focus behavior.
• Supporting browsers can still provide animated transitions.
• Other browsers receive ordinary navigation without animation.
• Less client-side JavaScript and lifecycle management is required.
• <ClientRouter /> can remain a documented opt-in for projects that need persistent state or application-like navigation.

Our proposed direction is therefore to:

1. Refactor the affected scripts so they do not depend on <ClientRouter />.
2. Move to native cross-document View Transitions.
3. Give paginated routes distinct titles, such as “Blog – Page 2.”
4. Add a clear results heading containing the current page information.
5. Consider linking pagination directly to the results region as an additional usability improvement.

With genuine MPA navigation restored, I do not think programmatic focus management should be required by default. The browser can handle document focus normally, while the improved title, heading and optional results fragment provide clearer orientation.

With all that said, it would genuinely be a big improvement to step away from the initial SPA behavior we introduced and move back to the native MPA behavior of View Transitions. We'll have to test it thoroughly though since it also affects a lot of the components that have been altered to work with the <ClientRouter />. We'll get back to it 🙂