|Summary:||AX: [ATK] We need to be smarter about flattening and the accessible text implementation|
|Product:||WebKit||Reporter:||Joanmarie Diggs <jdiggs>|
|Component:||Accessibility||Assignee:||Joanmarie Diggs <jdiggs>|
|Severity:||Normal||CC:||aboxhall, apinheiro, cfleizach, commit-queue, dmazzoni, gyuyoung.kim, jcraig, mario, samuel_white, webkit-bug-importer|
|Version:||528+ (Nightly build)|
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 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 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 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.