So if I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
Bug 1894091 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons depending on error states or success states, and swapping out these text areas would be only a few lines of code and easily testable. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation. But, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons (and even the `<textarea>` itself) depending on error states or success states, and swapping out these text areas would be only a few lines of code and easily testable. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation. But, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons (and even the `<textarea>` itself) depending on error states or success states that occur within the panel, and swapping out these text areas would be only a few lines of code and easily testable. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation. But, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons (and even the `<textarea>` itself) depending on error states or success states that occur within the panel. Modifying it to swap out these text areas would be only a few lines of code and easily testable. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation. But, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons (and even the `<textarea>` itself) depending on error states or success states that occur within the panel. Modifying it to swap out these text areas would be only a few lines of code and easily testable. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out these text areas would be only a few lines of code and easily testable. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out these text areas would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out these text areas would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves?
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out these text areas would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textareas>` would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textarea>` elements would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textarea>` elements would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems reasonable to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textarea>` elements would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems justified to me based on the end-user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textarea>` elements would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems justified to me based on the end user experience it would provide. --- If I'm understanding correctly, the flow would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textarea>` elements would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems justified to me based on the end user experience it would provide. --- If I'm understanding correctly, the flow that Jamie described would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textarea>` elements would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something unusual like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code even if it seems justified to me based on the end user experience it would provide. --- If I'm understanding correctly, the flow that Jamie described would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.
I personally don't feel that it's _that_ hacky. There is already logic to show/hide different buttons, message bars, and even the `<textarea>` itself depending on error states or success states that occur within the panel. Modifying it to swap out two mutually exclusive `<textarea>` elements would be only a few lines of code as well as being easily testable in automation. Someone cleaning it up later would break my own test cases before they realized they broke an a11y-aspect out in the wild. Plus, I'd never implement something unusual like this without extra clear documentation as to why it was implemented that way. Nonetheless, I do understand if people don't want that kind of logic in the code, even if it seems justified to me based on the end user experience it would provide. --- If I'm understanding correctly, the flow that Jamie described would be to announce "Translation complete" and leave it up to the screen-reader user to navigate to the text area and select the text themselves? If that is an experience that Jamie is okay with, then I am also okay with it.