Bug 135689 – AX: event.target should sometimes be a descendant element on AXPress-triggered mouse clicks

• Component: Accessibility
• Status: RESOLVED FIXED

[James Craig]

AXPress sometimes triggers the click event (and other mouse events) on a different element than a real mouse click would use. We should try using hit-testing at the center of the clickable (link, button, etc.) to determine the element on which to initiate the mouse events. In some cases, it may be better to a descendant node as the event.target. If the center point hit-test results in a node that is not a descendant, we should ignore it and fire the event on the original element.

To be clear, I don’t think WebKit is doing anything wrong, but there are times when web authors do silly things. VO+Space doesn’t work, but routing the mouse to an element and triggering a simulated mouse click does. This idea is mainly to work around those web authoring problems, and make it so that AXPress works in more scenarios.

[Radar WebKit Bug Importer]

<rdar://problem/17941920>

[James Craig]

Looks like at least part of this was done in bug 131426. I'll try to attach a test case where it doesn't work.

[James Craig]

Created attachment 236174 [details]
test case

[James Craig]

In the attached test case, the second clickable element (image inside button) is trigger by AXPress, but the first clickable element (span inside link) is only clickable with the mouse, not AXPress.

[James Craig]

Created attachment 236176 [details]
updated test case

updated test case logs the event target and includes some failure cases to ensure we don't click things that are positioned over the top of the element in the VO cursor.

[James Craig]

Might need to ignore any child that does not accept pointer events via CSS. See bug 11395 and Dean's write-up: http://www.webkit.org/specs/PointerEventsProperty.html

[chris fleizach]

Created attachment 243353 [details]
patch

[chris fleizach]

Note: I did not cover the cases in your original test case about the intercepting view. We have code specifically to fall back to the original element if we hit-test to a non-descendant. I'm worried about removing that code.

[Mario Sanchez Prada]

Comment on attachment 243353 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=243353&action=review

> LayoutTests/accessibility/press-target-uses-text-descendant-node.html:21
> +     .target {
> +         background-color: yellow;
> +      }

Nit: this looks misaligned

[chris fleizach]

http://trac.webkit.org/changeset/177532