Bug 133613

Summary: AX: Heuristic: Avoid exposing an element as clickable if mouse event delegation is handled on an element with any explicit ARIA role, including presentation.
Product: WebKit Reporter: James Craig <jcraig>
Component: AccessibilityAssignee: chris fleizach <cfleizach>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, apinheiro, cdumez, cfleizach, commit-queue, dmazzoni, dylan, gijs, jcraig, jdiggs, mario, samuel_white, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 136247    
Attachments:
Description Flags
patch none

Description James Craig 2014-06-07 16:05:05 PDT 
AX: Heuristic: Avoid exposing an element as clickable if mouse event delegation is handled on an element with any explicit ARIA role, including presentation.

WebKit exposes clickable state on any element that is a click, mousedown, or mouseup event listener, due to the common Web anti-pattern of making non-button elements act like buttons:

  <span onclick="handleClick(this)">this is clickable (improper usage b/c no button role)</span>

We avoid exposing it if event delegation is handled on the body element, because this is common with some JS frameworks (including SproutCore). 

<body onclick="handleClick(this);">
  <button>this is clickable (proper usage)</button>
  <span>due to the body delegation pattern, we assume this is not clickable, even though it technically is</span>
</body>

This leaves an ambiguous middle ground where event delegation could be used properly or improperly on non-body elements. 

<div class="delegate" onclick="handleClick(this);">
  <button>this is clickable (proper usage)</button>
  <span>this is also clickable (improper usage)</span>
  <p>This is also clickable, even though the web app does not handle the event. There's no way for WebKit to know if the event will be handled, so we still expose the clickable status to the accessibility APIs.</p>
</div>

Unfortunately the DOM of the proper and improper examples is programmatically indistinguishable, so we err on the side of exposing mildly more verbose output to the user, because the alternative means they may not be able to perceive clickable elements in the more-common anti-pattern case. I think this is the right choice, but we may be able to further distinguish these cases with some additional heuristics, such as where or not delegate listener has an explicitly defined ARIA role, including the "presentation" role.

<div role="presentation" onclick="handleClick(this);">
  <button>this is a button (user assumes clickable)</button>
  <span>this is no longer exposed as clickable because of the explicit role on the delegate</span>
</div>

This might be enough for authors that know what they are doing to avoid the additional unwanted "clickables" but we'd still catch the other 99% of cases where lazy web authors do accessibility and event handling incorrectly.
Comment 1 James Craig 2014-06-07 16:07:04 PDT 
*** Bug 133608 has been marked as a duplicate of this bug. ***
Comment 2 James Craig 2014-06-07 16:22:18 PDT 
<rdar://problem/17218708>
Comment 3 James Craig 2014-06-10 21:58:42 PDT 
This should probably be expandable like the data table heuristics in AccessibilityTable::isDataTable().
Comment 4 James Craig 2014-08-26 01:21:05 PDT 
More in Bug 136247
Comment 5 chris fleizach 2014-12-17 17:34:35 PST 
Created attachment 243471 [details]
patch
Comment 6 WebKit Commit Bot 2014-12-18 15:25:38 PST 
Comment on attachment 243471 [details]
patch

Clearing flags on attachment: 243471

Committed r177536: <http://trac.webkit.org/changeset/177536>
Comment 7 WebKit Commit Bot 2014-12-18 15:25:41 PST 
All reviewed patches have been landed.  Closing bug.
Comment 8 Chris Dumez 2014-12-18 15:32:34 PST 
I am getting this linking error now:
Undefined symbols for architecture x86_64:
  "__ZNK7WebCore19AccessibilityObject19supportsPressActionEv", referenced from:
      -[WebAccessibilityObjectWrapper accessibilityActionNames] in WebAccessibilityObjectWrapperMac.o
Comment 9 chris fleizach 2014-12-18 15:49:26 PST 
(In reply to comment #8)
> I am getting this linking error now:
> Undefined symbols for architecture x86_64:
>   "__ZNK7WebCore19AccessibilityObject19supportsPressActionEv", referenced
> from:
>       -[WebAccessibilityObjectWrapper accessibilityActionNames] in
> WebAccessibilityObjectWrapperMac.o

Looking into it now
Comment 10 Chris Dumez 2014-12-18 15:50:27 PST 
(In reply to comment #9)
> (In reply to comment #8)
> > I am getting this linking error now:
> > Undefined symbols for architecture x86_64:
> >   "__ZNK7WebCore19AccessibilityObject19supportsPressActionEv", referenced
> > from:
> >       -[WebAccessibilityObjectWrapper accessibilityActionNames] in
> > WebAccessibilityObjectWrapperMac.o
> 
> Looking into it now

Thanks, I am trying a clean build right now in case this fixes it.
Comment 11 Chris Dumez 2014-12-18 15:54:30 PST 
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I am getting this linking error now:
> > > Undefined symbols for architecture x86_64:
> > >   "__ZNK7WebCore19AccessibilityObject19supportsPressActionEv", referenced
> > > from:
> > >       -[WebAccessibilityObjectWrapper accessibilityActionNames] in
> > > WebAccessibilityObjectWrapperMac.o
> > 
> > Looking into it now
> 
> Thanks, I am trying a clean build right now in case this fixes it.

Never mind, a clean build fixed it. Sorry about the noise.