Closed Bug 1894233 Opened 7 months ago Closed 6 months ago

Navigating inside the translated text box using UP/DOWN ARROWs is not working correctly

Categories

(Firefox :: Translations, defect, P4)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
Accessibility Severity s3
Tracking Status
firefox-esr115 --- disabled
firefox125 --- disabled
firefox126 --- disabled
firefox127 --- disabled
firefox128 --- verified
firefox129 --- verified

People

(Reporter: danibodea, Assigned: nordzilla)

References

Details

(Keywords: access)

Attachments

(2 files)

Note

  • When the user selects a larger paragraph of text and triggers the Select Translations panel, he will need to navigate inside the text box to read all the translated text. When tapping the DOWN ARROW once, the panel scrolls to the very end of the text. Then if he taps the UP ARROW, the focus will move from the last row, one row at a time, without any visual effect of the focus, until the focus reaches the top of the text area (~12 presses of the UP ARROW), only then, the text is scrolled up, one row at a time. Scrolling back down will happen just the same, ~12 ghost taps until the text is being scrolled. Both the scrolling down and scrolling up using the keyboard is ineffective.

Found in

  • Nightly v127.0a1

Affected versions

  • Nightly v127.0a1

Tested platforms

  • Affected platforms: Windows, MacOS, Ubuntu
  • Unaffected platforms: -

Steps to reproduce

  1. Select a very large paragraph of text.
  2. Open the context menu and select the Translate option.
  3. Tap the DOWN ARROW button.
    Expected result: The text is being scrolled 1 or a few rows at a time.
    Actual result: The text is being scrolled to the end.
  4. Tap the UP ARROW button.
    Expected result: The text is being scrolled 1 or a few rows at a time.
    Actual result: The text does not scroll up for the first 12 taps, then scrolls one row at a time.

Regression range

  • Not a regression.

This is a demo of the issue. I should mention that key presses cannot be recorded and that the exact steps are described in the description of this bug.

Blocks: 1870363
Severity: -- → S3
Has STR: --- → yes
Keywords: access
OS: Unspecified → All
Hardware: Unspecified → Desktop
Accessibility Severity: --- → s3
See Also: → 1870354
Priority: -- → P3
Priority: P3 → P4

Investigation

I did a bit of investigation into this. There are a couple different things going on here.


Arrow keys jump the scrollbar to the bottom

The first bit of odd behavior here is that pressing the down arrow after the translated text populates will jump to the bottom of the scrollable content.

The reason this happens is that even though the <textarea> element is readonly, it still has a logical cursor that is affected by the arrow keys. When the <textarea> populates the translated text I am ensuring that the scroll bar is scrolled to the top, but I am missing logic to move the actual cursor back to the beginning.

Since the view is scrolled to the top, but the cursor is still at the bottom, pressing an arrow key will scroll the view to where the cursor is currently.

Adding logic to move the cursor to the beginning textArea.setSelectionRange(0, 0) at the code location linked above should fix this.


Arrow keys move the cursor

The other consideration here is that the arrow keys are moving the actual cursor, not the scrollbar.

While there may be an opportunity for an improved custom default experience here, I would say that this is actually expected behavior for a <textarea> element.

I should note that there are direct ways for all 3 operating systems to move the scroll bar, rather than the cursor:

  • macOS fn + arrow
  • Linux page_up or page_down
  • Windows page_up or page_down

My worry is that changing the default association of the arrow keys may actually decrease usability for keyboard-navigation users. I will have to defer to Anna for an official recommendation here.


Summary

  • I am going to land a patch that ensures and verifies through tests that the cursor always starts at the beginning of the translated text.

  • I am not sure that changing the default association of the arrow keys to manipulate the scroll bar would be a good idea, especially since there are already keybindings for that purpose, but I will defer to Anna on this.

Flags: needinfo?(ayeddi)

This patch ensures that, in addition to setting the scroll bar to
the top of the <textarea> when the translated text is populated,
the cursor is also set to the beginning of the text.

Assignee: nobody → enordin
Status: NEW → ASSIGNED
Assignee: nobody → enordin
Pushed by enordin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1d218e0de296 Ensure SelectTranslationsPanel cursor is set to start r=ohall,translations-reviewers
Keywords: leave-open
Blocks: 1894098

(In reply to Erik Nordin [:nordzilla] from comment #2)

Arrow keys move the cursor

The other consideration here is that the arrow keys are moving the actual cursor, not the scrollbar.

While there may be an opportunity for an improved custom default experience here, I would say that this is actually expected behavior for a <textarea> element.

I should note that there are direct ways for all 3 operating systems to move the scroll bar, rather than the cursor:

  • macOS fn + arrow
  • Linux page_up or page_down
  • Windows page_up or page_down

My worry is that changing the default association of the arrow keys may actually decrease usability for keyboard-navigation users. I will have to defer to Anna for an official recommendation here.


Summary

  • I am going to land a patch that ensures and verifies through tests that the cursor always starts at the beginning of the translated text.

  • I am not sure that changing the default association of the arrow keys to manipulate the scroll bar would be a good idea, especially since there are already keybindings for that purpose, but I will defer to Anna on this.

Thank you very much for the investigation, Erik! I agree that we do not want to change the default behavior of the <textarea> in general, but also in this case specifically, because it both looks like one and is programmatically a <textarea> (announced as such by a screen reader), thus different groups of users would be expecting it to behave like a <textarea>.

Thank you for fixing the initial cursor placement - this would be a huge help in the reviewing the text, again, with and without a screen reader running too.

@Daniel, would you be able to confirm the initial position issue was resolved with the patch? If so, from the Accessibility team's perspective, we could resolve the bug.

To change handling of the arrow navigation to scrolling, we could file a separate bug as enhancement for UX team to update the expected output area (i.e. to an <output> or other element, but we'd need to test to confirm the arrow navigation is as expected by default)

Flags: qe-verify+
Flags: needinfo?(dbodea)
Flags: needinfo?(ayeddi)

I can confirm that the (invisible) cursor falls at the beginning of the textarea when the panel is opened. The new behavior is certainly less confusing when the user attempts to read the text. In my personal opinion, it would be best if the cursor was also visible so that the user could see an effect of pressing the first few down-arrow buttons in an attempt to navigate. While also considering we have other ways to scroll the text, I believe this issue can be closed. Please set the status of the report as resolved so that I can verify. Thank you.

Verified in Nightly v129.0a1 and Beta v128.0b1 on Windows10, MacOS11 and Ubuntu22.

Flags: needinfo?(dbodea) → needinfo?(enordin)
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Flags: needinfo?(enordin)
Resolution: --- → FIXED

Closing report as verified based on the latest comments. Thank you!

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: