New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 785129 link

Starred by 1 user

Issue metadata

Status: Started
Owner:
Last visit > 30 days ago
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

a11y: AT software compatibility - ensure that the order of caret events is consistent

Project Member Reported by leberly@chromium.org, Nov 15 2017

Issue description

This is part of a trio bugs around AT software and:
A) Text editing
B) Caret tracking and
C) Address bar

This bug is for item A: Ensure that the order of caret events is consistent, i.e. EVENTOBJECT_LOCATIONCHANGED should always come before the relevant IA2_TEXT_CARET_MOVED.

Assigned to Nektarios since he has already started work on this. 

This bug is related to the following bugs:
item B: Allow assistive technology to retrieve the character after the caret from the caret object
https://bugs.chromium.org/p/chromium/issues/detail?id=784969

item C: a11y: AT software compatibility - Ensure that in the address bar will return a valid location
https://bugs.chromium.org/p/chromium/issues/detail?id=785131

Another related bug not listed above
# Valid caret bounds should be reported when the container containing the caret moves, not only when the caret offset changes
https://bugs.chromium.org/p/chromium/issues/detail?id=782843

 

Comment 1 Deleted

Summary: a11y: AT software compatibility - ensure that the order of caret events is consistent (was: a11y: magnification - ensure that the order of caret events is consistent)
Description: Show this description
Description: Show this description
Update from a user using Chrome 62.0.3202.94 (64 bit) on Windows 10 (64 bit v-1703.15063.674)

I don’t see a caret object created event (but no matter if a move event comes in, we will treat that as created as well)

I don’t see a caret object destroyed event (but generally, a focus event occurs which causes ZoomText to declare the caret destroyed until another move)

I get 2 caret move events which provide different information in different cases
Using www.freedomscientific.com as the reference webpage, this is what I saw happen:

When the caret is positioned in the URL edit field
IA2_EVENT_TEXT_CARET_MOVED is fired regardless of whether the field contains any text (THIS IS GOOD)
Asking for the location of the event’s IAccessible returns the location of the entire edit field which is of no use since we want the caret’s location
Calls to IAccessibleText get_characterextents specifying IA2_TEXT_OFFSET_CARET & IA2CoordinateType::IA2_COORDTYPE_SCREEN_RELATIVE returned 0x80004001L: // E_NOTIMPL
Calls to IAccessibleText get_textAtOffset specifying IA2_TEXT_OFFSET_CARET, IA2TextBoundaryType::IA2_TEXT_BOUNDARY_CHAR, were successful and returned the character to the right of the caret location

EVENT_OBJECT_LOCATIONCHANGE event with OBJID_CARET is  fired regardless of whether the field contains any text (THIS IS GOOD)
Calls to GetAccessibleObjectFromWindow with OBJID_CARET returned an IAccessible whose
location was the caret
name was “edit”
value was “”
Calls to IAccessibleText get_textAtOffset specifying IA2_TEXT_OFFSET_CARET, IA2TextBoundaryType::IA2_TEXT_BOUNDARY_CHAR, always returns ‘E’ as in “Edit” the name of the control

When the caret is positioned in the Search edit field in the upper right side on that webpage
IA2_EVENT_TEXT_CARET_MOVED is  fired regardless of whether the field contains any text (THIS IS GOOD)
Asking for the location of the event’s IAccessible returns the location of the entire edit field which is of no use since we want the caret’s location
If there is no text in the edit control, calls to IAccessibleText get_characterextents specifying IA2_TEXT_OFFSET_CARET & IA2CoordinateType::IA2_COORDTYPE_SCREEN_RELATIVE returned an empty rect (THIS IS BAD – there is a blinking caret there)
If there is text in the edit control, calls to IAccessibleText get_characterextents specifying IA2_TEXT_OFFSET_CARET & IA2CoordinateType::IA2_COORDTYPE_SCREEN_RELATIVE returned the location of the caret
Calls to IAccessibleText get_textAtOffset specifying IA2_TEXT_OFFSET_CARET, IA2TextBoundaryType::IA2_TEXT_BOUNDARY_CHAR, were successful and returned the character to the right of the caret location (if there was one)
EVENT_OBJECT_LOCATIONCHANGE event with OBJID_CARET is  fired only if  the field contains text (THIS IS BAD)
If the field has text, actually got two EVENT_OBJECT_LOCATIONCHANGE events from different windows and Calls to GetAccessibleObjectFromWindow with OBJID_CARET returned an IAccessible with a location as follows:
Chrome_RenderWidgetHostHWND first with previous caret location
Chrome_WidgetWin_1 second with correct caret location
Calls to GetAccessibleObjectFromWindow with OBJID_CARET returned an IAccessible whose
location was the caret
name was “edit”
value was “”
Calls to IAccessibleText get_textAtOffset specifying IA2_TEXT_OFFSET_CARET, IA2TextBoundaryType::IA2_TEXT_BOUNDARY_CHAR, always returns ‘E’ as in “Edit” the name of the control

A quick check in a reply to an email in gmail yielded:
IA2_EVENT_TEXT_CARET_MOVED not fired at all
EVENT_OBJECT_LOCATIONCHANGE event with OBJID_CARET is  fired twice (same window classes as above) only if  the field (or line)  contains text (THIS IS BAD)
If the field has text, actually got two EVENT_OBJECT_LOCATIONCHANGE events from different windows and Calls to GetAccessibleObjectFromWindow with OBJID_CARET returned an IAccessible with a location as follows:
Chrome_RenderWidgetHostHWND first with last caret location
Chrome_WidgetWin_1 second with correct caret location
Calls to GetAccessibleObjectFromWindow with OBJID_CARET returned an IAccessible whose
location was the caret
name was “edit”
value was “”
Labels: -Pri-2 Pri-3
Labels: a11y-secondary

Comment 8 by nek...@chromium.org, Dec 10 2017

Status: Started (was: Assigned)

Comment 9 by nek...@chromium.org, Dec 10 2017

Labels: -a11y-secondary win-a11y
Caret tracking.
Labels: editing
Labels: -editing caret-tracking

Sign in to add a comment