### STR: 1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 1. Ensure an NVDA screen reader is running 1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA 1. Select a text (using mouse, likely, because screen readers are not yet supporting static text selection) and open a context menu/right click 1. Navigate to and activate `Translate Selection to English` 1. Confirm the dialog is opened and observe the screen reader announcements ### Expected: 1. When a dialog is opened, [it is expected that the focus would be placed to allow the user to discover the content of the dialog without the need to navigate backwards](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/#keyboardinteraction), which is usually for the content to be placed at the top of the content or on the container itself _or_ to the main action but while making sure [the content of the alertdialog would be announced by a screen reader](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/). 1. In this case, since the size of the dialog is short, and the primary action/target of the dialog is the translation, we could retain the focus on the `<textarea>` but it's important to use `aria-describedby` that is referring to the container of the dialog, to its content, so a screen reader user would become aware that there is, in fact, some content and controls that are placed above the current focus position. ### Actual: 1. Only the dialog role itself is announced by screen readers, no information is provided about the settings or to/from language controls. Focus is placed on the translated output itself, which may cause users of assistive technology to think that there are no other content above, no way to toggle the to/from languages and/or change the translation settings. ### Remediation: 1. To the `role=alertdialog` container, add `aria-describedby` reference to the ID attribute of the dialog itself - this would allow a screen reader to also read the content of the dialog to a user while the focus is placed not at the top of the dialog, without the need to reverse navigate it. Refer to [the WAI ARIA alertdialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/)
Bug 1894098 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
### STR: 1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 1. Ensure a screen reader is running 1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA 1. Select a text (using mouse, likely, because screen readers are not yet supporting static text selection) and open a context menu/right click 1. Navigate to and activate `Translate Selection to English` 1. Confirm the dialog is opened and observe the screen reader announcements ### Expected: 1. When a dialog is opened, [it is expected that the focus would be placed to allow the user to discover the content of the dialog without the need to navigate backwards](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/#keyboardinteraction), which is usually for the content to be placed at the top of the content or on the container itself _or_ to the main action but while making sure [the content of the alertdialog would be announced by a screen reader](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/). 1. In this case, since the size of the dialog is short, and the primary action/target of the dialog is the translation, we could retain the focus on the `<textarea>` but it's important to use `aria-describedby` that is referring to the container of the dialog, to its content, so a screen reader user would become aware that there is, in fact, some content and controls that are placed above the current focus position. ### Actual: 1. Only the dialog role itself is announced by screen readers, no information is provided about the settings or to/from language controls. Focus is placed on the translated output itself, which may cause users of assistive technology to think that there are no other content above, no way to toggle the to/from languages and/or change the translation settings. ### Remediation: 1. To the `role=alertdialog` container, add `aria-describedby` reference to the ID attribute of the dialog itself - this would allow a screen reader to also read the content of the dialog to a user while the focus is placed not at the top of the dialog, without the need to reverse navigate it. Refer to [the WAI ARIA alertdialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/)
### STR: 1. Ensure `browser.translations.select.enable` is set to `true` in the about:config 1. Ensure a screen reader is running 1. Navigate to a page in a language different from the OS, i.e. for English machine: `data:text/html,<p lang="es_ES">Como estas?</p>` or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA 1. Select a text (using mouse or by following the [NVDA 2024.1 guide for Native Selection Mode](https://www.nvaccess.org/files/nvda/documentation/userGuide.html?#NativeSelectionMode)) and open a context menu/right click 1. Navigate to and activate `Translate Selection to English` 1. Confirm the dialog is opened and observe the screen reader announcements ### Expected: 1. When a dialog is opened, [it is expected that the focus would be placed to allow the user to discover the content of the dialog without the need to navigate backwards](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/#keyboardinteraction), which is usually for the content to be placed at the top of the content or on the container itself _or_ to the main action but while making sure [the content of the alertdialog would be announced by a screen reader](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/). 1. In this case, since the size of the dialog is short, and the primary action/target of the dialog is the translation, we could retain the focus on the `<textarea>` but it's important to use `aria-describedby` that is referring to the container of the dialog, to its content, so a screen reader user would become aware that there is, in fact, some content and controls that are placed above the current focus position. ### Actual: 1. Only the dialog role itself is announced by screen readers, no information is provided about the settings or to/from language controls. Focus is placed on the translated output itself, which may cause users of assistive technology to think that there are no other content above, no way to toggle the to/from languages and/or change the translation settings. ### Remediation: 1. To the `role=alertdialog` container, add `aria-describedby` reference to the ID attribute of the dialog itself - this would allow a screen reader to also read the content of the dialog to a user while the focus is placed not at the top of the dialog, without the need to reverse navigate it. Refer to [the WAI ARIA alertdialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/)