1170242 - Setting the caret via AtkText should scroll content into view

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Attachment: scrolling.html

Steps to reproduce:
1. Load the attached test case in Firefox and be sure the first line is at the top of the window.
2. Launch Accerciser
3. In Accerciser, select the second child element (ROLE_SECTION) of the document frame in Accerciser's tree of accessibles.
4. In Accerciser's iPython console, type acc.queryText().setCaretOffset(4) to set the caret at offset 4 in the div which is scrolled off screen.

Expected result: The line in which the caret was placed would be scrolled into view.

Actual result: The caret is successfully placed in the div which is scrolled off screen, but that div is not scrolled into view.

Impact: An AT that controls navigation (like the Orca screen reader) is often presenting content which is not visible -- no problem for a user who is blind and working alone. But if the Orca user is working with a sighted peer, or using Orca along with magnification software which tracks the caret location, that peer or low vision user cannot see what is being presented.

Comment 1

[Joanmarie Diggs]

Another impact: There are dynamic pages in which additional content is displayed when the user scrolls towards the bottom of the page. DuckDuckGo search results is one such page.

Orca sets the caret position via AtkText as the user navigates. If where the caret is being set is a non-focusable element, Firefox won't scroll the page and the additional content won't be displayed until the user scrolls (e.g. via Page Down).

Comment 2

[Zahari Yurukov]

Please raise the priority of this bug. Sometimes, it's not just a minor inconvenience, but the user actually needs to click something that he/she reads, and that is impossible if it's off the screen.
Yes, it's bad authoring if an active element haven't been made focusable or doesn't react to the keyboard, but that's the real world.
Thanks for your understanding.

Comment 3

[Alexandre ARNAUD]

I'm visual impaired and I use the Gnome Zoom Applet, it's very lack of time to scroll with mouse in the same time as Orca.

For your information in Thunderbird, both in mail and web view from feeds I haven't this issue.

Best regards.

Comment 4

[Samuel Thibault]

Attachment: proposed fix

Hello,

Here is a working patch: HyperTextAccessible.cpp is simply missing calling ScrollIntoView to make sure that the new focus is visible, just like nsFrameSelection::MoveCaret does for normal keypresses.

Samuel

Comment 5

[alexander :surkov (:asurkov)]

Comment on attachment 8910749 [details] [diff] [review]
proposed fix

Review of attachment 8910749 [details] [diff] [review]:
-----------------------------------------------------------------

looks good

Comment 6

[Matthew N. [:MattN]]

Hello Samuel,

Please update your commit message to match the desired format[1] and include author information in your patch.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities#Commit_message_restrictions

Comment 7

[Samuel Thibault]

Attachment: proposed fix

Here is the same patch reworked with proper commit line and author

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9cbc9faa5c99
On accessibility SetSelectionRange, scroll the selection into view. r=surkov

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9cbc9faa5c99