RESOLVED FIXED Bug 144639
AX: [ATK] We need to be smarter about flattening and the accessible text implementation
https://bugs.webkit.org/show_bug.cgi?id=144639
Summary AX: [ATK] We need to be smarter about flattening and the accessible text impl...
Joanmarie Diggs
Reported 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.
Attachments
Patch (20.69 KB, patch)
2016-04-26 20:42 PDT, Joanmarie Diggs
no flags
Patch (22.26 KB, patch)
2016-04-27 17:28 PDT, Joanmarie Diggs
no flags
Radar WebKit Bug Importer
Comment 1 2015-05-05 14:05:26 PDT
Joanmarie Diggs
Comment 2 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.)
Joanmarie Diggs
Comment 3 2016-04-26 20:42:58 PDT
Joanmarie Diggs
Comment 4 2016-04-26 21:19:10 PDT
Comment on attachment 277439 [details] Patch Chris: When you have a spare moment, please review. Thanks!
chris fleizach
Comment 5 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
Joanmarie Diggs
Comment 6 2016-04-27 17:28:09 PDT
Joanmarie Diggs
Comment 7 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.
WebKit Commit Bot
Comment 8 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>
WebKit Commit Bot
Comment 9 2016-04-28 06:12:21 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.