Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

77%
+5 −0
Q&A 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 API1, specifically the value of history.scrollRestoration. Quoting the HTML spec's scroll restoration mode paragraph: ...

1 answer  ·  posted 2mo ago by toraritte‭  ·  last activity 2mo ago by toraritte‭

#8: Nominated for promotion by user avatar Alexei‭ · 2024-04-17T06:52:12Z (about 2 months ago)
#7: Post edited by user avatar toraritte‭ · 2024-04-16T00:50:37Z (about 2 months ago)
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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][3]<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][4]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][5] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][6]), but the behavior described below are the same for all users regardless:
  • 1. 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][5]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][5] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • ---
  • **update**:
  • + `chrome`: Wanted to ask this on the [chromium-discuss][7] Google Group, but none of my messages went through, so opened [an issue][8].
  • + `firefox`: [Asked about this in the Firefox chat][9] as well.
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://stackoverflow.com/questions/38879526/is-history-api-consistent-across-modern-browsers
  • [4]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [5]: https://societyfortheblind.org/
  • [6]: https://www.freedomscientific.com/products/software/jaws/
  • [7]: https://groups.google.com/a/chromium.org/g/chromium-discuss
  • [8]: https://issues.chromium.org/issues/334275634
  • [9]: https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org/$mdaKabMH5VwEJnWRk38XYViWMLxffsaptOSrQiIiSIE?via=mozilla.org&via=matrix.org&via=tchncs.de
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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][3]<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][4]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][5] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][6]), but the behavior described below are the same for all users regardless:
  • 1. 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][5]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][5] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • ---
  • **update**:
  • + `chrome`: Wanted to ask this on the [chromium-discuss][7] Google Group, but none of my messages went through, so opened [an issue][8] (which has been confirmed to be a bug).
  • + `firefox`: [Asked about this in the Firefox chat][9] as well.
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://stackoverflow.com/questions/38879526/is-history-api-consistent-across-modern-browsers
  • [4]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [5]: https://societyfortheblind.org/
  • [6]: https://www.freedomscientific.com/products/software/jaws/
  • [7]: https://groups.google.com/a/chromium.org/g/chromium-discuss
  • [8]: https://issues.chromium.org/issues/334275634
  • [9]: https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org/$mdaKabMH5VwEJnWRk38XYViWMLxffsaptOSrQiIiSIE?via=mozilla.org&via=matrix.org&via=tchncs.de
#6: Post edited by user avatar toraritte‭ · 2024-04-13T19:27:16Z (2 months ago)
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • ---
  • **update**:
  • + `chrome`: Wanted to ask this on the [chromium-discuss][6] Google Group, but none of my messages went through, so opened [an issue][7].
  • + `firefox`: [Asked about this in the Firefox chat][8] as well.
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
  • [6]: https://groups.google.com/a/chromium.org/g/chromium-discuss
  • [7]: https://issues.chromium.org/issues/334275634
  • [8]: https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org/$mdaKabMH5VwEJnWRk38XYViWMLxffsaptOSrQiIiSIE?via=mozilla.org&via=matrix.org&via=tchncs.de
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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][3]<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][4]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][5] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][6]), but the behavior described below are the same for all users regardless:
  • 1. 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][5]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][5] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • ---
  • **update**:
  • + `chrome`: Wanted to ask this on the [chromium-discuss][7] Google Group, but none of my messages went through, so opened [an issue][8].
  • + `firefox`: [Asked about this in the Firefox chat][9] as well.
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://stackoverflow.com/questions/38879526/is-history-api-consistent-across-modern-browsers
  • [4]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [5]: https://societyfortheblind.org/
  • [6]: https://www.freedomscientific.com/products/software/jaws/
  • [7]: https://groups.google.com/a/chromium.org/g/chromium-discuss
  • [8]: https://issues.chromium.org/issues/334275634
  • [9]: https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org/$mdaKabMH5VwEJnWRk38XYViWMLxffsaptOSrQiIiSIE?via=mozilla.org&via=matrix.org&via=tchncs.de
#5: Post edited by user avatar toraritte‭ · 2024-04-13T17:12:41Z (2 months ago)
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • ---
  • **update**: Wanted to ask this on the [chromium-discuss][6] Google Group, but none of my messages went through, so opened [an issue][7].
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
  • [6]: https://groups.google.com/a/chromium.org/g/chromium-discuss
  • [7]: https://issues.chromium.org/issues/334275634
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • ---
  • **update**:
  • + `chrome`: Wanted to ask this on the [chromium-discuss][6] Google Group, but none of my messages went through, so opened [an issue][7].
  • + `firefox`: [Asked about this in the Firefox chat][8] as well.
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
  • [6]: https://groups.google.com/a/chromium.org/g/chromium-discuss
  • [7]: https://issues.chromium.org/issues/334275634
  • [8]: https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org/$mdaKabMH5VwEJnWRk38XYViWMLxffsaptOSrQiIiSIE?via=mozilla.org&via=matrix.org&via=tchncs.de
#4: Post edited by user avatar toraritte‭ · 2024-04-13T16:51:51Z (2 months ago)
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • ---
  • **update**: Wanted to ask this on the [chromium-discuss][6] Google Group, but none of my messages went through, so opened [an issue][7].
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
  • [6]: https://groups.google.com/a/chromium.org/g/chromium-discuss
  • [7]: https://issues.chromium.org/issues/334275634
#3: Post edited by user avatar toraritte‭ · 2024-04-13T11:33:27Z (2 months ago)
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b><b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
#2: Post edited by user avatar toraritte‭ · 2024-04-13T11:33:09Z (2 months ago)
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.)
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
  • As far as I can tell, it is in part determined by the HTML spec's History API<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.) The example in the "Context" section below seems to confirm this.
  • <sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
  • <sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>
  • <sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it),
  • [2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki),
  • [3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>
  • ---
  • ##### Context
  • [We][4] are trying to troubleshoot a page of legacy web application that is mostly used by screen reader users (via [JAWS][5]), but the behavior described below are the same for all users regardless:
  • 1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|
  • 2. 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"
  • >
  • ```
  • 3. Click on the browser's back button.
  • Focus:
  • + `JAWS`: the "Plan" button in step 2.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
  • + `Firefox`<sup><b>4</b><b>5</b></sup>: the "Plan" button in step 2.
  • 4. Click on the browser's back button.
  • Focus:
  • + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
  • + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
  • + `Firefox`<sup><b>4</b>,<b>5</b></sup>: the link used to navigate away from the page in step 1.
  • <sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>
  • <sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>
  • <sup>\[5]: For the record, Firefox does retain scroll information in this page in [our][4] web app, but when I tested [this MDN page](https://developer.mozilla.org/en-US/docs/Web/API/History_API/Working_with_the_History_API), 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>`...</sup>
  • [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  • [2]: https://stackoverflow.com/a/65632874/1498178
  • [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  • [4]: https://societyfortheblind.org/
  • [5]: https://www.freedomscientific.com/products/software/jaws/
#1: Initial revision by user avatar toraritte‭ · 2024-04-13T02:03:05Z (2 months ago)
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<sup><b>1</b></sup>, specifically the value of [`history.scrollRestoration`][1]. Quoting the HTML spec's [scroll restoration mode][1] 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][2]<sup><b>2</b></sup> 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<sup><b>1</b></sup>, that is.)

<sup>\[1]: `HTML spec`: [7.2 APIs related to navigation and session history](https://html.spec.whatwg.org/multipage/nav-history-apis.html) > [7.2.5 The History interface](https://html.spec.whatwg.org/multipage/nav-history-apis.html#the-history-interface); [7.4 Navigation and session history](https://html.spec.whatwg.org/multipage/browsing-the-web.html)</sup><br>
<sup>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;`MDN`: [History API][3]</sup>

<sup>\[2]: The threads I have found in this topic ([1](https://stackoverflow.com/questions/26781507/when-a-user-clicks-a-browsers-back-button-the-focus-should-go-back-to-where-it), 
[2](https://stackoverflow.com/questions/25168861/how-to-take-user-back-to-where-they-scrolled-to-on-the-previous-page-when-clicki), 
[3](https://stackoverflow.com/questions/29203312/how-can-i-retain-the-scroll-position-of-a-scrollable-area-when-pressing-back-but)) show activity from around 2014 and / or provide an answer without much explanation or reference to sources.</sup>

---

##### Context

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

1. 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][4]|blabla|Goodworker, Sally|Bigboss, Paige|Assigned|

2. 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"
   >
   ```

3. Click on the browser's back button.

   Focus:
   + `JAWS`: the "Plan" button in step 2.
   + `Chrome`<sup><b>3</b></sup>: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
   + `Firefox`<sup><b>4</b></sup>: the "Plan" button in step 2.

4. Click on the browser's back button.

   Focus:
   + `JAWS`: `<body>`; on <kbd>TAB</kbd>, focus jumps back to link used to navigate away.
   + `Chrome`<sup><b>3</b></sup>: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
   + `Firefox`<sup><b>4</b></sup>: the link used to navigate away from the page in step 1.

<sup>\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)</sup>

<sup>\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.</sup>


  [1]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-restoration-mode
  [2]: https://stackoverflow.com/a/65632874/1498178
  [3]: https://developer.mozilla.org/en-US/docs/Web/API/History_API
  [4]: https://societyfortheblind.org/
  [5]: https://www.freedomscientific.com/products/software/jaws/