I checked role="text" on parent element removed the default_action="click" for all children. This seems to work fine and clickable is no more announced. But this may not be applicable to all scenarios.

Please note this was tested with simple page on Chrome 52

Have you compared the behavior to Firefox?

We specifically changed our code to better match Firefox, which I believe has the same heuristic.

Comment 7 by nek...@chromium.org, Today (4 hours ago)
I wouldn't mind changing what Chrome exposes but we need to figure out a way to tell users whether something is clickable. The assistive software you mention announces "clickable" for a good reason. Many web apps have widgets that don't use the correct ARIA or HTML attributes to indicate their role. So, a blind user has no way of knowing what they can activate or not. Many times the context, i.e. what the page says, is not enough. You need to know exactly where and what to click.
Excluding click handlers on the body element was just a heuristic.

-----------------------------------------------------------------
@nek...

The current fix ( Issue 595222 ) is actually misleading Visually Impaired Users to think that ALL text contents are "clickable"(s).
Just because a parent container has a "click-or-mouse-related" event listener, it doesn't mean every single text that it contains should be clickable. perhaps, there should be a role attribute (presentation) to handle this type situation.

@dmazz. Firefox works correctly. This worked well in chrome 43 & 49.

I don't understand what you mean by "a role presentation". How are you envisioning this to work?
Bare in mind what I said before: Many site authors don't add any ARIA attributes and don't use the correct HTML tags to indicate that something is clickable, so we need to rely on a heuristic.
My hope is to be able to improve or completely get rid of this heuristic.
Do you have any suggestions for how to do that?

I tried the following in Firefox:
data:text/html,<div onclick="console.log('hi')"><p>this is a test</p></div>
The text is announced as clickable by Jaws.
Can you paste a code snippet?

<div id="container">
     <h1>Simple Heading Text</h1>
     <p>Lorem ipsum dolor sit amet.</p>
     <p>consectetur adipiscing elit</p>
     <div>Sub div text</div>
</div>
<script src="https://code.jquery.com/jquery-3.1.1.js"></script>
<script>
   $('#container').on('click', 'div', function () {console.log($(this).text());});
</script>

------- 
I got the same behavior in Firefox ESR as well. 
I get your point about the heuristic. 
I was suggesting the omission of default_action='click' when a specific role (presentation, text, ...) is added directly to the element or one of its parents (ex: <div id="container" role="presentation">).

@nek  What version of did you try?  I tried both FF45ESR and FF51Developer and neither seemed to state text was clickable when an parent had a click event

While I like the attempt at giving the blind user more information on what is clickable, I feel like maybe this patch was too aggressive.  Would it be possible to only apply this behavior if the element is 'interactive'?  So, for instance, any natively interactive element like button would be announced as clickable, but non native ones would only be announced as such if they were given a tabindex to make them interactive.  This would map the behavior for an interactive element, or closely match it.  If a dev wires up a click handler to a non interactive element and does not specify a tabindex, I would consider that bug by the developer or an intentionally 'hidden' feature.

I tried with Firefox 49, which is the very latest stable version.
I think we would be happy to change the heuristic to make it less aggressive, after we determine the right balance. Clearly, the current behavior is too sensitive.
I'll discuss with my team.

FYI: in Firefox(ESR), texts are announced as "clickable" in the previous sample (I provided) until a 'role' attribute is added to the ALL parent containers with a 'click' event listener. 

It looks like the heuristic in FF is more specific to cases where no role is specified by the developer.
 
Sample:
	<div id="container" role="region"> // role="region" or role="presentation"
        	<h1>Simple Heading Text</h1>
        	<p>Lorem ipsum dolor sit amet.</p>
		<p>consectetur adipiscing elit</p>
		<div>Sub div text</div>
		<div id="sub-container" role="region"> // note the role="region" since this div has an event now
			<div>
				<div>Text within a nested div</div>
			</div>
			<table>
			<tr><th>Header 1</th><th>Header 2</th><th>Header 3</th></tr>
			<tr><td>Text 1</td><td>Text 2</td><td>Text 3</td></tr>
			<tr><td>Text 1</td><td>Text 2</td><td>Text 3</td></tr>
			</table>
				
		</div>	
	</div>
        <script src="https://code.jquery.com/jquery-3.1.1.js"></script>
        <script>
	  $('#container').on('click', 'div', function () {console.log($(this).text());});
	  $('#sub-container').on('click', 'div', function () {console.log($(this).text());});
        </script>

Is there any plan to resolve this issue in the near future?

Per Drew:
"I'm still hearing a lot of "clickable" links/text that isn't actually clickable, as well as the inverse: clickable text not marked as clickable (and thus not actionable."

Related:  issue 689201 ,  issue 679435 ,  issue 709592 .