What determines where the focus goes back to when clicking on a browser's back button?

As far as I can tell, it is in part determined by the HTML spec's History API¹, specifically the value of history.scrollRestoration. Quoting the HTML spec's scroll restoration mode paragraph:

"auto"
The user agent is responsible for restoring the scroll position upon navigation.

"manual"
The page is responsible for restoring the scroll position and the user agent does not attempt to do so automatically.

This answer² illustrates how the "manual" option can be used, but what about "auto"? Is the behavior then set by user agent implementations? If this is true, is my assumption correct that one would have to take the "manual" route to ensure that the back button's behavior is deterministic across browsers? (If they properly implemented the History API¹, that is.) The example in the "Context" section below seems to confirm this.

^{[1]: HTML spec: 7.2 APIs related to navigation and session history > 7.2.5 The History interface; 7.4 Navigation and session history}
^{MDN: History API}

^{[2]: The threads I have found in this topic (1,
2,
3) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.}

Context

We are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via JAWS), but the behavior described below are the same for all users regardless:

Click on a client link in a long <table> of rows along the lines of:

Assignment Date Client Notes Instructor Assigned By Status

April 12, 2024 Doe, John blabla Goodworker, Sally Bigboss, Paige Assigned

Assignment Date	Client	Notes	Instructor	Assigned By	Status
April 12, 2024	Doe, John	blabla	Goodworker, Sally	Bigboss, Paige	Assigned

On the client's page, the user clicks on a button; such as:

<input type="button"
       aria-label="Plans"
       onclick="location.href='/plans/1234';"
       value="Plans"
>

Click on the browser's back button.

Focus:
- JAWS: the "Plan" button in step 2.
- Chrome³: <body>, but when hitting TAB, the focus jumps to the very first link, and not to the button clicked previously.
- Firefox^4,5: the "Plan" button in step 2.
Click on the browser's back button.

Focus:
- JAWS: <body>; on TAB, focus jumps back to link used to navigate away.
- Chrome³: <body>; on TAB, focus jumps to link in the next line.
- Firefox^4,5: the link used to navigate away from the page in step 1.

^{[3]: Chrome DevTools: Track element focus}

^{[4]: Determined by issuing document.activeElement in the dev console after each back button press.}

^{[5]: For the record, Firefox does retain scroll information in this page in our web app, but when I tested this MDN page, the results were inconsistent. For example, search for "single-page application", the first result is a link, clicking on it, then going back shows the anchor as focused. There is a link right below saying fetch(), but clicking and going back will show that the focus is on <body>...}

update:

chrome: Wanted to ask this on the chromium-discuss Google Group, but none of my messages went through, so opened an issue (which has been confirmed to be a bug).
firefox: Asked about this in the Firefox chat as well.

Short answer

The HTML specification only addresses scroll position restoration behavior, so the main factors that influences where focus will land when navigating the browser history are:

user agent implementations
JavaScript
accessibility attributes
browser extensions

At the moment, the only solution to make this behaviour consistent seems to be using JavaScript to restore focus manually (see section 3.). (TODO: are there other ways?)

Long answer

The statement above is based on my understanding of the 7.4 Navigation and session history section of the HTML spec. (The very first paragraph is sobering).

ASIDE: scroll position vs focus(ed element)

Understanding the difference is important because scroll position is not useful for screen readers. This seems to be the gist:

Scroll position is the visible part of a web page and is independent on where the focus is.¹

Focused element is an HTML element that a user selected using the TAB key on the keyboard (i.e., "tabbable").²

^{[1]: It is way more complex than this; I started here, followed the "reading advice", but gave up after more than twenty open tabs (the modern equivalent of the Fighting Fantasy book's 1..2..23 finger-placeholders rule).}

^{[2]: A sloppy way to put it, but seems to boil down to this, and it is especially valid when looking from an accessibility viewpoint. In the context of this question, focused elements are also interactive elements that modify the navigation history and not elements that were made "tabbable" (see web.dev's Focus article)³.}

^{[3]: HTMX can make any element an interactive one, but they won't become "tabbable" as far as I know. HTMX's hx-push-url attribute helps with navigation history consistency, but getting if focused will probably require considerable scripting effort.}

1. Influencing factors

1.1 User agent implementations

None of the major browser implementations have formal specifications (or I couldn't find them), and the only way to answer this question is to look at the code (if possible) or ask.

TODO: Are there user agents where this behavious is configurable? (e.g., settings, compile flags)

Chrome

The focus is not restored after going back; see Chromium issue.
Edge

Same as Chrome (after all, it is Chromium-based, if I remember it correctly).
Firefox

Inconsistent behaviour; see Firefox bug report.
Safari

Same as Chrome; filed a report on https://www.apple.com/feedback/safari.html (which is not public) and not on the WebKit site because I'm very unfamiliar with Safari / WebKit, not to mention their relationship.

1.2 JavaScript

Web pages with may have scripts embedded that manipulate focus.

1.3 HTML attributes

The MDN article on the autofocus global attribute already addresses its potential issues with screen readers. ARIA also has extra roles and attributes to improve accessibility (some that also affect focus), but they tend to be applied incorrectly.

1.4 Browser extensions

The same argument applies as under section "1.2 JavaScript" above.

2. Screen readers

Decided to create a separate section for screen readers, because I know little to nothing about how they work. For example, are they considered user agents or do they rely solely on existing browsers?

I presume it is the latter, because otherwise users wouldn't have to use Chrome, Firefox, etc., but screen readers do seem to have an internal mechanism to smooth over differences in user agent implementations:

2.1 JAWS

A Chrome + JAWS user reported that when navigating back, JAWS will announce the focus to be on <body>, but when pressing TAB, the focus will jump to the next "tabbable" element right after the one that was used to navigate away initially.

For example:

User clicks on link "Doe, John" in a table row on the page.

Assignment Date Client Notes Instructor Assigned By Status

April 12, 2024 ->Doe, John<- blabla Goodworker, Sally Bigboss, Paige Assigned
Press ALT+← to go back to the previous page.
Press TAB, and the focus is reported to be on the link "Goodworker, Sally":

Assignment Date Client Notes Instructor Assigned By Status

April 12, 2024 Doe, John blabla ->Goodworker, Sally<- Bigboss, Paige Assigned

Assignment Date	Client	Notes	Instructor	Assigned By	Status
April 12, 2024	`->`Doe, John`<-`	blabla	Goodworker, Sally	Bigboss, Paige	Assigned

Assignment Date	Client	Notes	Instructor	Assigned By	Status
April 12, 2024	Doe, John	blabla	`->`Goodworker, Sally`<-`	Bigboss, Paige	Assigned

TODO: Report this behaviour to Freedom Scientific, because the previous focus target was obviously saved by JAWS, but it is unintuitive, especially for users new to JAWS and/or web browsing.

TODO: Test JAWS with other user agents as well.

2.2 NVDA

2.3 Windows Narrator

2.4 Apple VoiceOver

TODO: Finish sections above by testing their behaviour the same way as with JAWS.

TODO: List other screen readers, however niche. (See 1, 2, 3, for example.)

3. Make behaviour consistent using JavaScript

TODO: These notes are little more than guesswork.
For existing websites: browser extensions?..
When developing a new web app:

One implementation is by adding event listeners to:

Interactive elements to store their reference when clicked

window to restore focus when navigating back in history.

This snippet will have to be tested:
function storeFocus() {
    sessionStorage.setItem('focusedElementId', document.activeElement.id);
}

function restoreFocus() {
    const focusedElementId = sessionStorage.getItem('focusedElementId');
    if (focusedElementId) {
        const focusedElement = document.getElementById(focusedElementId);
        if (focusedElement) { focusedElement.focus(); }
    }
}

window.addEventListener('popstate', function(event) {
    restoreFocus();
});

document.getElementsByTagName('a').addEventListener('click', function() {
    storeFocus();
    window.location.href = 'another-page.html';
});