Software Development

#8: Nominated for promotion by

Alexei‭ · 2024-04-17T06:52:12Z (30 days ago)

Copy Link

Raw

Markdown

#7: Post edited by

toraritte‭ · 2024-04-16T00:50:37Z (about 1 month ago)

Copy Link

Raw

Markdown

As far as I can tell, it is in part determined by the HTML spec's History API1, 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]2 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]1, 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](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)
`MDN`: [History API][4]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
---
**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 API1, 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]2 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]1, 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](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)
`MDN`: [History API][4]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
---
**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

toraritte‭ · 2024-04-13T19:27:16Z (about 1 month ago)

Copy Link

Raw

Markdown

As far as I can tell, it is in part determined by the HTML spec's History API1, 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]2 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 API1, 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](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)
~~       `MDN`: [History API][3]~~
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
---
**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 API1, 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]2 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]1, 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](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)
`MDN`: [History API][4]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
---
**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

toraritte‭ · 2024-04-13T17:12:41Z (about 1 month ago)

Copy Link

Raw

Markdown

As far as I can tell, it is in part determined by the HTML spec's History API1, 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]2 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 API1, 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](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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
---
**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 API1, 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]2 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 API1, 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](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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
---
**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

toraritte‭ · 2024-04-13T16:51:51Z (about 1 month ago)

Copy Link

Raw

Markdown

As far as I can tell, it is in part determined by the HTML spec's History API1, 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]2 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 API1, 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](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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
[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 API1, 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]2 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 API1, 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](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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
---
**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

toraritte‭ · 2024-04-13T11:33:27Z (about 1 month ago)

Copy Link

Raw

Markdown

As far as I can tell, it is in part determined by the HTML spec's History API1, 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]2 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 API1, 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](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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
~~+ `Firefox`45: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
[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 API1, 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]2 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 API1, 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](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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4,5: 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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
[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

toraritte‭ · 2024-04-13T11:33:09Z (about 1 month ago)

Copy Link

Raw

Markdown

As far as I can tell, it is in part determined by the HTML spec's History API1, 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]2 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 API1, that is.)
\[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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
~~+ `Firefox`4: 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`3: `<body>`; on <kbd>TAB</kbd>, focus jumps to link in the next line.
~~+ `Firefox`4: the link used to navigate away from the page in step 1.~~
\[3]: [Chrome DevTools: Track element focus](https://developer.chrome.com/docs/devtools/accessibility/focus)
\[4]: Determined by issuing `document.activeElement` in the dev console after each back button press.
[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 API1, 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]2 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 API1, 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](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)
`MDN`: [History API][3]
\[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.
---
##### 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`3: `<body>`, but when hitting <kbd>TAB</kbd>, the focus jumps to the very first link, and **not** to the button clicked previously.
+ `Firefox`4<b>5</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`3: `<body>`; on <kbd>TAB</kbd>, 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](https://developer.chrome.com/docs/devtools/accessibility/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][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>`...
[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

toraritte‭ · 2024-04-13T02:03:05Z (about 1 month ago)

Copy Link

Raw

Markdown

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/

html accessibility html5-history screen-readers

Communities

Post History