Could you please provide sample test file and details steps, that would help us in triaging the issue from TE-end

Marking as available without a repro because a developer should look at this one directly. 

I think this was fixed by bug 788696 - can you check Chrome Canary and see if it's working there now?

I just tested Canary 65.0.3310.0 and it's still broken. I had some trouble testing because my code wasn't being called at all due to a change in accLocation() which is now returning incorrect/different data for items that are not visible. In previous builds, accLocation() would return coordinates that are beyond the bounds of my window and I was using this to decide if to try and scroll the item into view and to calculate scroll offsets based on the size of the object. In 64.0.3310.0, accLocation() is returning a rect that is always in the visible window - items off the bottom of the visible page are all 1 pixel high and reported on the bottom raster line of visible rectangle.

Please can you restore accLocation() to how it used to work in Chrome 63 (or earlier).

Also, I should note that IAcessible2::scrollToPoint(IA2_COORDTYPE_PARENT_RELATIVE,...) does work correctly. I have been able to modify my code to use this instead of _SCREEN_RELATIVE, so this is no longer a high priority for me.

The intent of the change to add clipping to accLocation was so that screen readers wouldn't show bounding boxes outside of the visible window.

I disagree. Clipping of bounding box hi-lighting is a screen reader or magnifier problem. The screen reader knows the window rect and the focus rect and could do this quite easily. You shouldn't be changing the behavior of the accessibility API to fix bugs in screen readers, especially if it then no longer complies with the specification. Also screen readers should call scrollTo() to make the object they are navigating to visible, so unless the object is larger than the window, or scrollTo() doesn't work it should never have to be clipped.

By not giving me the correct size and off screen position, you have made it impossible for me to scroll into view accurately without moving twice.

I no longer know if the element is visible or invisible by checking if the accLocation is within the parent window. If I want to call scrollToPoint() to position the element within certain margins, or maybe center it in the window, I can't because I don't know the size of the element is. 

So now to center an object (in Chrome) or get it within a specific margin, I have to guess a position (because I don't know the size), call scrollToPoint(), wait for the location to change, re-get the location, calculate a new position based on the new size and if it's different, call scrollToPoint() again?

Also, for our document reading system, our code assumes that if the content of a window scrolls, all of the objects will change location by the scrolling distance. We then don't have to call accLocation() to get new positions of anything that we have cached that has scrolled (which is faster). 

Every other implementation of accLocation I have encountered gives me the correct width, height and off-screen location for objects that are scrolled out-of-view, and the SYSTEM_STATE_OFFSCREEN and/or SYSTEM_STATE_HIDDEN flags are set.

Please make Chrome behave the same as every other application's implementation of accLocation().