Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...`` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area. This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element. But I wonder if a better "hacky" solution here, might be to go back to something similar to that first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Bug 1894091 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...`` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area. This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element. But I wonder if a better "hacky" solution here, might be to go back to something similar to that first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area. This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element. But I wonder if a better "hacky" solution here, might be to go back to something similar to that first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element. But I wonder if a better "hacky" solution here, might be to go back to something similar to that first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element. But I wonder if a better "hacky" solution here, might be to go back to something similar to that first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. But I wonder if a better "hacky" solution here, might be to go back to something similar to that first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. But I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to that first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. But I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-life="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text (I think, if I'm understanding correctly). The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the text area? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. when they are swapped. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution here, might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. when they are swapped. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements. One for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. when they are swapped. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), I believe would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. when they are swapped. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the text area visually selected when it says `Translating...` and then when the translation comes through, the highlighted `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. when they are swapped. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` would look identical to the `<textarea>` and we could potentially see flashes of different styles etc. when they are swapped. We fixed it, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` styling would look identical to the `<textarea>` styling, and we could potentially see flashes of different styles etc. when they are swapped. We fixed it with the animated background-image spinner, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` styling would look identical to the `<textarea>` styling, and we could potentially see flashes of different styles etc. when they are swapped. We fixed it with the animated background-image spinner, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved before release, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible. I wish there was some sort of way to use a `mutationObserver` and trigger the screen reader to start reading or something, but it doesn't sound like that API exists.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element because I couldn't figure out a clean way to do the background spinner animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` styling would look identical to the `<textarea>` styling, and we could potentially see flashes of different styles etc. when they are swapped. We fixed it with the animated background-image spinner, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved before release, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible. I wish there was some sort of way to use a mutation observer and trigger the screen reader to start reading or something, but it doesn't sound like that API exists.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element to display the `Translating...` placeholder text because I couldn't figure out a clean way to do the spinner SVG animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` styling would look identical to the `<textarea>` styling, and we could potentially see flashes of different styles etc. when they are swapped. We fixed it with the animated background-image spinner, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved before release, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible. I wish there was some sort of way to use a mutation observer and trigger the screen reader to start reading or something, but it doesn't sound like that API exists.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element to display the `Translating...` placeholder text because I couldn't figure out a clean way to do the spinner SVG animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` styling would look identical to the `<textarea>` styling, and we could potentially see flashes of different styles when they are swapped. We fixed it with the animated background-image spinner, and now there is only one `<textarea>` element that updates its text. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved before release, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible. I wish there was some sort of way to use a mutation observer and trigger the screen reader to start reading or something, but it doesn't sound like that API exists.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element to display the `Translating...` placeholder text because I couldn't figure out a clean way to do the spinner SVG animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` styling would look identical to the `<textarea>` styling, and we could potentially see flashes of different styles when they are swapped. We fixed this with the animated background-image spinner for the `<textarea>`, and now there is only one `<textarea>` element that updates its text between the `Translating...` placeholder and the translated text when it is ready. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved before release, but I'd like to try to find a way to do it without any extra visual highlighting of the text if possible. I wish there was some sort of way to use a mutation observer and trigger the screen reader to start reading or something, but it doesn't sound like that API exists.
Hey Emilio, ### Problem Summary We're running into an issue where mutating the text in the `<textarea>` from `Translating...` to whatever the translated text is, is not picking up for screen readers. There's nothing tracking mutations to the text area for screen readers. The solution that Anna posted just above, if I'm understanding correctly (see video in [comment 3](https://bugzilla.mozilla.org/show_bug.cgi?id=1894091#c3)), would have the text within the `<textarea>` visually selected when it says `Translating...` and then when the translation comes through, the selection on the `Translating...` text would be removed, which would announce `selection removed` for NVDA and then read the new text to the screen reader. The problem is that this feels a little bit hacky, forcing it to say "selection removed" like that. And it also has the visual downside of having the `Translating...` placeholder text to always be visually highlighted, which UX would like to avoid if possible. ### A Possible Solution? So, do you recall early on when I was implementing this, I was swapping out the `<textarea>` element with a `<div>` element to display the `Translating...` placeholder text because I couldn't figure out a clean way to do the spinner SVG animation inside the `<textarea>`? This was flagged in review because we couldn't really guarantee that every aspect of the `<div>` styling would look identical to the `<textarea>` styling, and we could potentially see flashes of different styles when they are swapped. We fixed this with the animated background-image spinner for the `<textarea>`, and now there is only one `<textarea>` element that updates its text between the `Translating...` placeholder and the translated text when it is ready. I wonder if a better (though still fairly hacky) solution might be to go back to something similar to the first approach, but instead of swapping out a `<div>` and a `<textarea>`, we would swap out two identically styled `<textarea>` elements: one for the placeholder text with the loading spinner background, and one for the translated text. I feel like since these are both `<textarea>` elements we would avoid the mismatched styling issue, and if they're both `aria-live="polite"` then it should announce it to screen readers whenever one gets hidden and the other becomes visible, right? --- Other than that, I'd be open to brainstorming further ideas. This is an A11y S2 bug, and needs to be solved before release, but I'd like to try to find a way to do it without announcing an unnecessary "selection removed," and without adding any extra visual highlighting of the placeholder text, if possible. I wish there was some sort of way to use a mutation observer and trigger the screen reader to start reading or something, but it doesn't sound like that API exists.