Bug 144639 - AX: [ATK] We need to be smarter about flattening and the accessible text implementation
Summary: AX: [ATK] We need to be smarter about flattening and the accessible text impl...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: All Linux
: P2 Normal
Assignee: Joanmarie Diggs
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-05-05 14:04 PDT by Joanmarie Diggs
Modified: 2016-04-28 06:12 PDT (History)
10 users (show)

See Also:


Attachments
Patch (20.69 KB, patch)
2016-04-26 20:42 PDT, Joanmarie Diggs
no flags Details | Formatted Diff | Diff
Patch (22.26 KB, patch)
2016-04-27 17:28 PDT, Joanmarie Diggs
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2015-05-05 14:04:56 PDT
Given:

  <div>
    <span>Span!</span>
    <h1>Foo</h1>
    <h2>Bar</h2>
    <p>Hello world</p>
  </div>

There is an object of ATK_ROLE_SECTION which implements the accessible text interface and contains the text of all of its children:

  'Span!\nFoo\n\nBar\n\nHello world'

Getting rid of the span results in the ATK_ROLE_SECTION going away.

While the above test case is not a big deal, given a page with a ton of content in a div with a single span, we're doing a lot of work getting all the text. That's bad for performance. Furthermore, for a variety of reasons, Orca is going to have to implement its own caret navigation for WebKitGtk. Having duplicated text (the headings and paragraphs are still there in the tree, correctly implementing AtkText) is really screwing things up. So we need to be smarter about our flattening.

I have some ideas which I'll pursue.
Comment 1 Radar WebKit Bug Importer 2015-05-05 14:05:26 PDT
<rdar://problem/20824771>
Comment 2 Joanmarie Diggs 2015-05-05 19:18:15 PDT
The idea, which I'm pursuing, will be to defer to WebCore Accessibility regarding inclusion of anonymous blocks. What we're doing in ATK at the moment is a heuristic hack. But before we can defer to WebCore, we need to sort out things like bug 144653. (And there will likely be many more such issues.)
Comment 3 Joanmarie Diggs 2016-04-26 20:42:58 PDT
Created attachment 277439 [details]
Patch
Comment 4 Joanmarie Diggs 2016-04-26 21:19:10 PDT
Comment on attachment 277439 [details]
Patch

Chris: When you have a spare moment, please review. Thanks!
Comment 5 chris fleizach 2016-04-27 00:21:58 PDT
Comment on attachment 277439 [details]
Patch

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

> Source/WebCore/accessibility/AccessibilityRenderObject.cpp:-2651
> -    if (node && (node->hasTagName(tdTag) || node->hasTagName(thTag)))

might be worth putting this in a helper method

> Source/WebCore/accessibility/atk/AccessibilityObjectAtk.cpp:91
> +        return renderObject->firstChildSlow() ? IncludeObject : DefaultBehavior;

will this handle inlines? would doing children().size() ? be a better check
Comment 6 Joanmarie Diggs 2016-04-27 17:28:09 PDT
Created attachment 277554 [details]
Patch
Comment 7 Joanmarie Diggs 2016-04-27 17:51:14 PDT
Comment on attachment 277439 [details]
Patch

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

> Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2652
> +        || (m_renderer->isAnonymous() && m_renderer->isTablePart()))

The helper method makes sense, but after making some additional test cases, I discovered that we don't want the anonymous check (fully-formed CSS tables which include "display:table-cell" have a non-anonymous renderer). "is<RenderTableCell>(m_renderer)" seems to be what we need. So I wound up not making the helper method in the new patch.

>> Source/WebCore/accessibility/atk/AccessibilityObjectAtk.cpp:91
>> +        return renderObject->firstChildSlow() ? IncludeObject : DefaultBehavior;
> 
> will this handle inlines? would doing children().size() ? be a better check

Since we're looking at the RenderObject children, it should. And if you mean calling AccessibilityObject::children().size(), is it safe to get the children of the AccessibilityObject in the method being used to determine if that AccessibilityObject should be included or ignored? Also, I don't think we want to base our decision on what AccessibilityObject children are present. (Though perhaps I am missing something.)

All of that said, your question led me to make additional test cases in order to see where WebCore Accessibility failed to include a paragraph element I'd expect included. And the only place I've found a difference is when that paragraph element's renderer has a RenderBlock child. So the new check looks explicitly for that condition and leaves the rest to WebCore Accessibility. And the new patch has more paragraph tests.
Comment 8 WebKit Commit Bot 2016-04-28 06:12:16 PDT
Comment on attachment 277554 [details]
Patch

Clearing flags on attachment: 277554

Committed r200188: <http://trac.webkit.org/changeset/200188>
Comment 9 WebKit Commit Bot 2016-04-28 06:12:21 PDT
All reviewed patches have been landed.  Closing bug.