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

James Craig
Reported 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.
Attachments
patch (6.93 KB, patch)
2014-12-17 17:34 PST, chris fleizach 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
James Craig
Comment 1 2014-06-07 16:07:04 PDT
*** Bug 133608 has been marked as a duplicate of this bug. ***
James Craig
Comment 2 2014-06-07 16:22:18 PDT
<rdar://problem/17218708>
James Craig
Comment 3 2014-06-10 21:58:42 PDT
This should probably be expandable like the data table heuristics in AccessibilityTable::isDataTable().
James Craig
Comment 4 2014-08-26 01:21:05 PDT
More in Bug 136247
chris fleizach
Comment 5 2014-12-17 17:34:35 PST
Created attachment 243471 [details] patch
WebKit Commit Bot
Comment 6 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>
WebKit Commit Bot
Comment 7 2014-12-18 15:25:41 PST
All reviewed patches have been landed. Closing bug.
Chris Dumez
Comment 8 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
chris fleizach
Comment 9 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
Chris Dumez
Comment 10 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.
Chris Dumez
Comment 11 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.
Note You need to log in before you can comment on or make changes to this bug.