[Webkit-unassigned] [Bug 125491] [ATK] Some elements do not show up in the ATK hierarchy

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=125491

Joanmarie Diggs (irc: joanie) <jdiggs at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #6 from Joanmarie Diggs (irc: joanie) <jdiggs at igalia.com> ---
(In reply to comment #0)
> There are some elements that are not showing up properly in the ATK
> hierarchy, so we need to investigate why and fix those that should actually
> show up:
> 
>  * <canvas>X</canvas>

Results are the same as on the Mac. If there is no fallback element, neither platform expose it. If there is a fallback element, both platforms expose it. We should add a new test case to roles-exposed.html. But this is not an ATK issue.

>  * <cite>X</cite>
>  * <code>X</code>

Results are the same as on the Mac insofar as the roles-exposed.html test is concerned. It's the same as with tags like i and b. Thus not an ATK issue.

>  * <img>
>  * <img alt="">
>  * <img src="foo.png">

Results are the same as on the Mac. It's just another flavor of canvas without fallback: Useless images are not exposed on either platform. Thus not an ATK issue.

>  * <div role="rowgroup">

Results are the same as on the Mac, at least as far as the roles-exposed.html test is concerned. Thus not an ATK issue.

>  * <div role="group">

Interestingly enough, the Mac isn't exposing this -- at least according to the expectations of roles-exposed.html. My guess (I've not dug into it) is that on the Mac, there is an AXGroup being exposed, but it's associated with a RenderObject child of the actual element. As a result, the thing which contains the ID attribute is not in the tree, but there's an object with the same role that is serving the same purpose. Thus the test results suggest it's not exposed, when functionally it is exposed. <insert shrug here> Regardless, ATK is actually exposing that actual element. So it's not only not an ATK issue, it's also not a case of it not showing up in the ATK hierarchy.

(In reply to comment #1)
> Some more:
> 
>  * <audio>

Regarding the roles-exposed.html test, our results are the same as on the Mac. This is another flavor of the canvas one. If you add a controls attribute to the audio element, then both the Mac and ATK have it in their hierarchy. We should add this condition to roles-exposed.html, but it's not an ATK issue.

>  * <video>

Not even in roles-exposed.html. But when I added it, both the Mac and ATK expose it as expected if it has a controls attribute. Unlike the audio element, both the Mac and ATK expose video even if it doesn't have the controls element. But, again, this is not an ATK issue and video elements do show up in the ATK hierarchy.


(In reply to comment #2)
> And more:
> 
>  * <tr>

And <caption> which, for some reason, was marked as "not to be exposed." Which is wrong. Captions should be exposed. Filed as bug 139005.

>  * <meter>
>  * <option>

As I mentioned in comment 4, this is indeed an ATK thing, but a testing one; not an accessibility one. The objects show up.... I just opened bug 139017 for it.

>  * <svg>

Same results as on the Mac. Not dug into it yet, but my guess is that it's like the useless images and canvas without fallback. Not an ATK issue.

Finally, what going through all of these things (and more) has taught me is: We really need to stop skipping stuff for ATK. :) That's bug 139016. I'll make this bug a dup of that one because that covers what you reported in the opening report.

*** This bug has been marked as a duplicate of bug 139016 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141123/382ca0fc/attachment-0002.html>