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

60%

+1 −0

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

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

posted 25d ago by toraritte‭ · edited 25d ago by toraritte‭

Answer

#3: Post edited by

toraritte‭ · 2024-04-21T21:43:46Z (25 days ago)

Copy Link

Raw

Markdown

~~## 1. Short answer~~
~~The [HTML specification][1] only addresses scroll position restoration behavior, so the main factors that determine where focus should land when navigating the browser history are:~~
* user agent implementations (see section 2.2)
* JavaScript
* accessibility attributes
* browser extensions
---
~~## 2. Long answer~~
The statement above is based on my understanding of the [7.4 Navigation and session history][2] section of the [HTML spec][1]. (The very first paragraph is sobering).
### 2.1 Scroll position vs focus(ed element)
~~Understanding the difference is important because [scroll position is not useful for screen readers][3]. This seems to be the gist:~~
~~+ **Scroll position** is the visible part of a web page and is independent on where the focus is.1~~
~~+ **Focused element** is an HTML element that a user selected using the <kbd>TAB</kbd> key on the keyboard (i.e., "tabbable").2~~
\[1]: It is way more complex than this; I started [here][4], followed the ["reading advice"][5], but gave up after more than twenty open tabs (the modern equivalent of the Fighting Fantasy book's 1..2..23 finger-placeholders rule).
\[2]: A sloppy way to put it, but seems to boil down to this, and it is especially valid when looking from an accessibility viewpoint. In the context of this question, focused elements are also interactive elements that modify the navigation history and not elements that were made "tabbable" (see web.dev's [Focus][6] article)3.
\[3]: HTMX can make any element an interactive one, but they won't become "tabbable" as far as I know. HTMX's [`hx-push-url` attribute][7] helps with navigation history consistency, but getting if focused will probably require considerable scripting effort.
~~### 2.2 User agent implementations~~
None of the major browser implementations have formal specifications (or I couldn't find them), and the only way to answer this question is to look at the code (if possible) or ask.
> TODO: Are there user agents where this behavious is configurable? (e.g., settings, compile flags)
* **Chrome**
The focus is not restored after going back; see [Chromium issue][8].
* **Edge**
Same as Chrome (after all, it is Chromium-based, if I remember it correctly).
* **Firefox**
Inconsistent behaviour; see [Firefox bug report][9].
* **Safari**
Same as Chrome; filed a report on https://www.apple.com/feedback/safari.html (which is not public) and not on the [WebKit site][10] because I'm very unfamiliar with Safari / WebKit, not to mention their relationship.
~~### 2.3 Screen readers~~
Decided to create a separate section for screen readers, because I know little to nothing about how they work. For example, are they considered user agents or do they rely solely on existing browsers?
I presume it is the latter, because otherwise users wouldn't have to use Chrome, Firefox, etc., but screen readers do seem to have an internal mechanism to smooth over differences in user agent implementations:
~~#### 2.3.1 JAWS~~
A Chrome + JAWS user reported that when navigating back, JAWS will announce the focus to be on `<body>`, but when pressing <kbd>TAB</kbd>, the focus will jump to the next "tabbable" element right after the one that was used to navigate away initially.
For example:
1. User clicks on link "Doe, John" in a table row on the page.
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
~~|April 12, 2024|`->`[Doe, John][11]`<-`|blabla|[Goodworker, Sally][11]|[Bigboss, Paige][11]|Assigned|~~
~~2. Press [  <kbd>ALT</kbd>+<kbd>←</kbd>  ][12] to go back to the previous page.~~
3. Press <kbd>TAB</kbd>, and the focus is reported to be on the link "Goodworker, Sally":
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
~~|April 12, 2024|[Doe, John][11]|blabla|`->`[Goodworker, Sally][11]`<-`|[Bigboss, Paige][11]|Assigned|~~
> TODO: Report this behaviour to Freedom Scientific, because the previous focus target was obviously saved by JAWS, but it is unintuitive, especially for users new to JAWS and/or web browsing.
> TODO: Test JAWS with other user agents as well.
~~#### 2.3.2 [NVDA][13]~~
~~#### 2.3.3 Windows Narrator~~
~~#### 2.3.4 Apple VoiceOver~~
> TODO: Finish sections above by testing their behaviour the same way as with JAWS.
~~> TODO: List other screen readers, however niche. (See [1][14], [2][15], [3][16], for example.)~~
[1]: https://html.spec.whatwg.org/
[2]: https://html.spec.whatwg.org/multipage/browsing-the-web.html
[3]: https://stackoverflow.com/a/54544257/1498178
[4]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#has-been-scrolled-by-the-user
[5]: https://html.spec.whatwg.org/multipage/introduction.html#how-to-read-this-specification
[6]: https://web.dev/learn/html/focus
[7]: https://htmx.org/attributes/hx-push-url/
[8]: https://issues.chromium.org/issues/334275634
[9]: https://bugzilla.mozilla.org/show_bug.cgi?id=1892634
[10]: https://webkit.org/reporting-bugs/
~~[11]: https://societyfortheblind.org/~~
~~[12]: https://www.freedomscientific.com/training/jaws/hotkeys/~~
~~[13]: https://www.nvaccess.org/download/~~
~~[14]: https://en.wikipedia.org/wiki/List_of_screen_readers~~
~~[15]: https://www.afb.org/blindness-and-low-vision/using-technology/assistive-technology-products/screen-readers~~
~~[16]: https://github.com/tspivey/tdsr~~

## Short answer
The [HTML specification][1] only addresses scroll position restoration behavior, so the main factors that influences where focus will land when navigating the browser history are:
* user agent implementations
* JavaScript
* accessibility attributes
* browser extensions
At the moment, the only solution to make this behaviour consistent seems to be using JavaScript to restore focus manually (see section 3.). (TODO: are there other ways?)
---
---
## Long answer
The statement above is based on my understanding of the [7.4 Navigation and session history][2] section of the [HTML spec][1]. (The very first paragraph is sobering).
> ASIDE: **scroll position** vs **focus(ed element)**
>
> Understanding the difference is important because [scroll position is not useful for screen readers][3]. This seems to be the gist:
>
> + **Scroll position** is the visible part of a web page and is independent on where the focus is.1
>
> + **Focused element** is an HTML element that a user selected using the <kbd>TAB</kbd> key on the keyboard (i.e., "tabbable").2
>
> \[1]: It is way more complex than this; I started [here][4], followed the ["reading advice"][5], but gave up after more than twenty open tabs (the modern equivalent of the Fighting Fantasy book's 1..2..23 finger-placeholders rule).
>
> \[2]: A sloppy way to put it, but seems to boil down to this, and it is especially valid when looking from an accessibility viewpoint. In the context of this question, focused elements are also interactive elements that modify the navigation history and not elements that were made "tabbable" (see web.dev's [Focus][6] article)3.
>
> \[3]: HTMX can make any element an interactive one, but they won't become "tabbable" as far as I know. HTMX's [`hx-push-url` attribute][7] helps with navigation history consistency, but getting if focused will probably require considerable scripting effort.
---
### 1. Influencing factors
#### 1.1 User agent implementations
None of the major browser implementations have formal specifications (or I couldn't find them), and the only way to answer this question is to look at the code (if possible) or ask.
> TODO: Are there user agents where this behavious is configurable? (e.g., settings, compile flags)
* **Chrome**
The focus is not restored after going back; see [Chromium issue][8].
* **Edge**
Same as Chrome (after all, it is Chromium-based, if I remember it correctly).
* **Firefox**
Inconsistent behaviour; see [Firefox bug report][9].
* **Safari**
Same as Chrome; filed a report on https://www.apple.com/feedback/safari.html (which is not public) and not on the [WebKit site][10] because I'm very unfamiliar with Safari / WebKit, not to mention their relationship.
#### 1.2 JavaScript
Web pages with may have scripts embedded that manipulate [focus][6].
#### 1.3 HTML attributes
The MDN article on [the `autofocus` global attribute][11] already addresses its potential issues with screen readers. [ARIA][12] also has extra roles and attributes to improve accessibility (some that also affect focus), [but they tend to be applied incorrectly][13].
#### 1.4 Browser extensions
The same argument applies as under section "1.2 JavaScript" above.
---
### 2. Screen readers
Decided to create a separate section for screen readers, because I know little to nothing about how they work. For example, are they considered user agents or do they rely solely on existing browsers?
I presume it is the latter, because otherwise users wouldn't have to use Chrome, Firefox, etc., but screen readers do seem to have an internal mechanism to smooth over differences in user agent implementations:
#### 2.1 JAWS
A Chrome + JAWS user reported that when navigating back, JAWS will announce the focus to be on `<body>`, but when pressing <kbd>TAB</kbd>, the focus will jump to the next "tabbable" element right after the one that was used to navigate away initially.
For example:
1. User clicks on link "Doe, John" in a table row on the page.
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
|April 12, 2024|`->`[Doe, John][14]`<-`|blabla|[Goodworker, Sally][14]|[Bigboss, Paige][14]|Assigned|
2. Press [  <kbd>ALT</kbd>+<kbd>←</kbd>  ][15] to go back to the previous page.
3. Press <kbd>TAB</kbd>, and the focus is reported to be on the link "Goodworker, Sally":
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
|April 12, 2024|[Doe, John][14]|blabla|`->`[Goodworker, Sally][14]`<-`|[Bigboss, Paige][14]|Assigned|
> TODO: Report this behaviour to Freedom Scientific, because the previous focus target was obviously saved by JAWS, but it is unintuitive, especially for users new to JAWS and/or web browsing.
> TODO: Test JAWS with other user agents as well.
#### 2.2 [NVDA][16]
#### 2.3 Windows Narrator
#### 2.4 Apple VoiceOver
> TODO: Finish sections above by testing their behaviour the same way as with JAWS.
> TODO: List other screen readers, however niche. (See [1][17], [2][18], [3][19], for example.)
---
### 3. Make behaviour consistent using JavaScript
> TODO: These notes are little more than guesswork.
>
> * **For existing websites**: browser extensions?..
>
> * **When developing a new web app**:
>
> One implementation is by adding event listeners to:
>
> 1. Interactive elements to store their reference when clicked
> 2. [`window`][20] to restore focus when navigating back in history.
>
> This snippet will have to be tested:
>
>
> ```javascript
> function storeFocus() {
> sessionStorage.setItem('focusedElementId', document.activeElement.id);
> }
>
> function restoreFocus() {
> const focusedElementId = sessionStorage.getItem('focusedElementId');
> if (focusedElementId) {
> const focusedElement = document.getElementById(focusedElementId);
> if (focusedElement) { focusedElement.focus(); }
> }
> }
>
> window.addEventListener('popstate', function(event) {
> restoreFocus();
> });
>
> document.getElementsByTagName('a').addEventListener('click', function() {
> storeFocus();
> window.location.href = 'another-page.html';
> });
> ```
[1]: https://html.spec.whatwg.org/
[2]: https://html.spec.whatwg.org/multipage/browsing-the-web.html
[3]: https://stackoverflow.com/a/54544257/1498178
[4]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#has-been-scrolled-by-the-user
[5]: https://html.spec.whatwg.org/multipage/introduction.html#how-to-read-this-specification
[6]: https://web.dev/learn/html/focus
[7]: https://htmx.org/attributes/hx-push-url/
[8]: https://issues.chromium.org/issues/334275634
[9]: https://bugzilla.mozilla.org/show_bug.cgi?id=1892634
[10]: https://webkit.org/reporting-bugs/
[11]: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/autofocus
[12]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
[13]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA#sect2
[14]: https://societyfortheblind.org/
[15]: https://www.freedomscientific.com/training/jaws/hotkeys/
[16]: https://www.nvaccess.org/download/
[17]: https://en.wikipedia.org/wiki/List_of_screen_readers
[18]: https://www.afb.org/blindness-and-low-vision/using-technology/assistive-technology-products/screen-readers
[19]: https://github.com/tspivey/tdsr
[20]: https://developer.mozilla.org/en-US/docs/Web/API/Window

#2: Post edited by

toraritte‭ · 2024-04-21T18:19:16Z (25 days ago)

Copy Link

Raw

Markdown

## 1. Short answer
~~User agent implementation determines where focus should land while navigating the history; the [HTML specification][1] only addresses scroll position restoration behavior.~~
---
## 2. Long answer
The statement above is based on my understanding of the [7.4 Navigation and session history][2] section of the [HTML spec][1]. (The very first paragraph is sobering).
### 2.1 Scroll position vs focus(ed element)
~~Understanding the difference is important because [scroll position is not useful for screen readers][3]. This seems to be gist:~~
~~+ **Scroll position** is the visible part of a web page and is independent of where the focus is.1~~
+ **Focused element** is an HTML element that a user selected using the <kbd>TAB</kbd> key on the keyboard (i.e., "tabbable").2
\[1]: It is way more complex than this; I started [here][4], followed the ["reading advice"][5], but gave up after more than twenty open tabs (the modern equivalent of the Fighting Fantasy book's 1..2..23 finger-placeholders rule).
\[2]: A sloppy way to put it, but seems to boil down to this, and it is especially valid when looking from an accessibility viewpoint. In the context of this question, focused elements are also interactive elements that modify the navigation history and not elements that were made "tabbable" (see web.dev's [Focus][6] article)3.
\[3]: HTMX can make any element an interactive one, but they won't become "tabbable" as far as I know. HTMX's [`hx-push-url` attribute][7] helps with navigation history consistency, but getting if focused will probably require considerable scripting effort.
### 2.2 User agent implementations
None of the major browser implementations have formal specifications (or I couldn't find them), and the only way to answer this question is to look at the code (if possible) or ask.
* **Chrome**
The focus is not restored after going back; see [Chromium issue][8].
* **Edge**
Same as Chrome (after all, it is Chromium-based, if I remember it correctly).
* **Firefox**
Inconsistent behaviour; see [Firefox bug report][9].
* **Safari**
Same as Chrome; filed a report on https://www.apple.com/feedback/safari.html (which is not public) and not on the [WebKit site][10] because I'm very unfamiliar with Safari / WebKit, not to mention their relationship.
### 2.3 Screen readers
Decided to create a separate section for screen readers, because I know little to nothing about how they work. For example, are they considered user agents or do they rely solely on existing browsers?
I presume it is the latter, because otherwise users wouldn't have to use Chrome, Firefox, etc., but screen readers do seem to have an internal mechanism to smooth over differences in user agent implementations:
#### 2.3.1 JAWS
A Chrome + JAWS user reported that when navigating back, JAWS will announce the focus to be on `<body>`, but when pressing <kbd>TAB</kbd>, the focus will jump to the next "tabbable" element right after the one that was used to navigate away initially.
For example:
1. User clicks on link "Doe, John" in a table row on the page.
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
|April 12, 2024|`->`[Doe, John][11]`<-`|blabla|[Goodworker, Sally][11]|[Bigboss, Paige][11]|Assigned|
2. Press [  <kbd>ALT</kbd>+<kbd>←</kbd>  ][12] to go back to the previous page.
3. Press <kbd>TAB</kbd>, and the focus is reported to be on the link "Goodworker, Sally":
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
|April 12, 2024|[Doe, John][11]|blabla|`->`[Goodworker, Sally][11]`<-`|[Bigboss, Paige][11]|Assigned|
> TODO: Report this behaviour to Freedom Scientific, because the previous focus target was obviously saved by JAWS, but it is unintuitive, especially for users new to JAWS and/or web browsing.
> TODO: Test JAWS with other user agents as well.
#### 2.3.2 [NVDA][13]
#### 2.3.3 Windows Narrator
#### 2.3.4 Apple VoiceOver
> TODO: Finish sections above by testing their behaviour the same way as with JAWS.
> TODO: List other screen readers, however niche. (See [1][14], [2][15], [3][16], for example.)
[1]: https://html.spec.whatwg.org/
[2]: https://html.spec.whatwg.org/multipage/browsing-the-web.html
[3]: https://stackoverflow.com/a/54544257/1498178
[4]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#has-been-scrolled-by-the-user
[5]: https://html.spec.whatwg.org/multipage/introduction.html#how-to-read-this-specification
[6]: https://web.dev/learn/html/focus
[7]: https://htmx.org/attributes/hx-push-url/
[8]: https://issues.chromium.org/issues/334275634
[9]: https://bugzilla.mozilla.org/show_bug.cgi?id=1892634
[10]: https://webkit.org/reporting-bugs/
[11]: https://societyfortheblind.org/
[12]: https://www.freedomscientific.com/training/jaws/hotkeys/
[13]: https://www.nvaccess.org/download/
[14]: https://en.wikipedia.org/wiki/List_of_screen_readers
[15]: https://www.afb.org/blindness-and-low-vision/using-technology/assistive-technology-products/screen-readers
[16]: https://github.com/tspivey/tdsr

## 1. Short answer
The [HTML specification][1] only addresses scroll position restoration behavior, so the main factors that determine where focus should land when navigating the browser history are:
* user agent implementations (see section 2.2)
* JavaScript
* accessibility attributes
* browser extensions
---
## 2. Long answer
The statement above is based on my understanding of the [7.4 Navigation and session history][2] section of the [HTML spec][1]. (The very first paragraph is sobering).
### 2.1 Scroll position vs focus(ed element)
Understanding the difference is important because [scroll position is not useful for screen readers][3]. This seems to be the gist:
+ **Scroll position** is the visible part of a web page and is independent on where the focus is.1
+ **Focused element** is an HTML element that a user selected using the <kbd>TAB</kbd> key on the keyboard (i.e., "tabbable").2
\[1]: It is way more complex than this; I started [here][4], followed the ["reading advice"][5], but gave up after more than twenty open tabs (the modern equivalent of the Fighting Fantasy book's 1..2..23 finger-placeholders rule).
\[2]: A sloppy way to put it, but seems to boil down to this, and it is especially valid when looking from an accessibility viewpoint. In the context of this question, focused elements are also interactive elements that modify the navigation history and not elements that were made "tabbable" (see web.dev's [Focus][6] article)3.
\[3]: HTMX can make any element an interactive one, but they won't become "tabbable" as far as I know. HTMX's [`hx-push-url` attribute][7] helps with navigation history consistency, but getting if focused will probably require considerable scripting effort.
### 2.2 User agent implementations
None of the major browser implementations have formal specifications (or I couldn't find them), and the only way to answer this question is to look at the code (if possible) or ask.
> TODO: Are there user agents where this behavious is configurable? (e.g., settings, compile flags)
* **Chrome**
The focus is not restored after going back; see [Chromium issue][8].
* **Edge**
Same as Chrome (after all, it is Chromium-based, if I remember it correctly).
* **Firefox**
Inconsistent behaviour; see [Firefox bug report][9].
* **Safari**
Same as Chrome; filed a report on https://www.apple.com/feedback/safari.html (which is not public) and not on the [WebKit site][10] because I'm very unfamiliar with Safari / WebKit, not to mention their relationship.
### 2.3 Screen readers
Decided to create a separate section for screen readers, because I know little to nothing about how they work. For example, are they considered user agents or do they rely solely on existing browsers?
I presume it is the latter, because otherwise users wouldn't have to use Chrome, Firefox, etc., but screen readers do seem to have an internal mechanism to smooth over differences in user agent implementations:
#### 2.3.1 JAWS
A Chrome + JAWS user reported that when navigating back, JAWS will announce the focus to be on `<body>`, but when pressing <kbd>TAB</kbd>, the focus will jump to the next "tabbable" element right after the one that was used to navigate away initially.
For example:
1. User clicks on link "Doe, John" in a table row on the page.
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
|April 12, 2024|`->`[Doe, John][11]`<-`|blabla|[Goodworker, Sally][11]|[Bigboss, Paige][11]|Assigned|
2. Press [  <kbd>ALT</kbd>+<kbd>←</kbd>  ][12] to go back to the previous page.
3. Press <kbd>TAB</kbd>, and the focus is reported to be on the link "Goodworker, Sally":
|Assignment Date|Client|Notes|Instructor|Assigned By|Status|
|--- |--- |--- |--- |--- |--- |
|April 12, 2024|[Doe, John][11]|blabla|`->`[Goodworker, Sally][11]`<-`|[Bigboss, Paige][11]|Assigned|
> TODO: Report this behaviour to Freedom Scientific, because the previous focus target was obviously saved by JAWS, but it is unintuitive, especially for users new to JAWS and/or web browsing.
> TODO: Test JAWS with other user agents as well.
#### 2.3.2 [NVDA][13]
#### 2.3.3 Windows Narrator
#### 2.3.4 Apple VoiceOver
> TODO: Finish sections above by testing their behaviour the same way as with JAWS.
> TODO: List other screen readers, however niche. (See [1][14], [2][15], [3][16], for example.)
[1]: https://html.spec.whatwg.org/
[2]: https://html.spec.whatwg.org/multipage/browsing-the-web.html
[3]: https://stackoverflow.com/a/54544257/1498178
[4]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#has-been-scrolled-by-the-user
[5]: https://html.spec.whatwg.org/multipage/introduction.html#how-to-read-this-specification
[6]: https://web.dev/learn/html/focus
[7]: https://htmx.org/attributes/hx-push-url/
[8]: https://issues.chromium.org/issues/334275634
[9]: https://bugzilla.mozilla.org/show_bug.cgi?id=1892634
[10]: https://webkit.org/reporting-bugs/
[11]: https://societyfortheblind.org/
[12]: https://www.freedomscientific.com/training/jaws/hotkeys/
[13]: https://www.nvaccess.org/download/
[14]: https://en.wikipedia.org/wiki/List_of_screen_readers
[15]: https://www.afb.org/blindness-and-low-vision/using-technology/assistive-technology-products/screen-readers
[16]: https://github.com/tspivey/tdsr

#1: Initial revision by

toraritte‭ · 2024-04-21T17:39:55Z (25 days ago)

Copy Link

Raw

Markdown

## 1. Short answer

User agent implementation determines where focus should land while navigating the history; the [HTML specification][1] only addresses scroll position restoration behavior.

---

## 2. Long answer

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

### 2.1 Scroll position vs focus(ed element)

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

+ **Scroll position** is the visible part of a web page and is independent of where the focus is.<sup><b>1</b></sup>

+ **Focused element** is an HTML element that a user selected using the <kbd>TAB</kbd> key on the keyboard (i.e., "tabbable").<sup><b>2</b></sup>

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

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

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

### 2.2 User agent implementations

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

* **Chrome**

  The focus is not restored after going back; see [Chromium issue][8].

* **Edge**

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

* **Firefox**

  Inconsistent behaviour; see [Firefox bug report][9].

* **Safari**

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

### 2.3 Screen readers

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

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

#### 2.3.1 JAWS

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

   For example:

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

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

   2. Press [&nbsp;&nbsp;<kbd>ALT</kbd>+<kbd>←</kbd>&nbsp;&nbsp;][12] to go back to the previous page.

   3. Press <kbd>TAB</kbd>, and the focus is reported to be on the link "Goodworker, Sally":

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

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

   > TODO: Test JAWS with other user agents as well.

#### 2.3.2 [NVDA][13]

#### 2.3.3 Windows Narrator

#### 2.3.4 Apple VoiceOver

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

> TODO: List other screen readers, however niche. (See [1][14], [2][15], [3][16], for example.)


  [1]: https://html.spec.whatwg.org/
  [2]: https://html.spec.whatwg.org/multipage/browsing-the-web.html
  [3]: https://stackoverflow.com/a/54544257/1498178
  [4]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#has-been-scrolled-by-the-user
  [5]: https://html.spec.whatwg.org/multipage/introduction.html#how-to-read-this-specification
  [6]: https://web.dev/learn/html/focus
  [7]: https://htmx.org/attributes/hx-push-url/
  [8]: https://issues.chromium.org/issues/334275634
  [9]: https://bugzilla.mozilla.org/show_bug.cgi?id=1892634
  [10]: https://webkit.org/reporting-bugs/
  [11]: https://societyfortheblind.org/
  [12]: https://www.freedomscientific.com/training/jaws/hotkeys/
  [13]: https://www.nvaccess.org/download/
  [14]: https://en.wikipedia.org/wiki/List_of_screen_readers
  [15]: https://www.afb.org/blindness-and-low-vision/using-technology/assistive-technology-products/screen-readers
  [16]: https://github.com/tspivey/tdsr

Communities

Post History