Bug 125857 – [ATK] Expose accessibility objects for <dl>, <dt> and <dd>

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Mario Sanchez Prada]

Now that ATK 2.11.4 has been released, we have the proper roles to map these elements:

 * <div role="dl"> shows up as ATK_ROLE_LIST, should be ATK_ROLE_DESCRIPTION_LIST
 * <div role="dt"> shows up as ATK_ROLE_UNKNOWN, should be ATK_ROLE_DESCRIPTION_TERM
 * <div role="dd"> shows up as ATK_ROLE_UNKNOWN, should be ATK_ROLE_DESCRIPTION_VALUE

[1] https://mail.gnome.org/archives/gnome-announce-list/2013-December/msg00007.html

[Mario Sanchez Prada]

Created attachment 219420 [details]
Patch proposal

[chris fleizach]

Comment on attachment 219420 [details]
Patch proposal

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

> Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp:638
> +        if (coreObject->isList() && toAccessibilityList(coreObject)->isDescriptionList())

It might be better to introduce a new WebCore role for DescriptionList, but I don't feel that strongly about it

[Mario Sanchez Prada]

(In reply to comment #2)
> (From update of attachment 219420 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=219420&action=review
> 
> > Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp:638
> > +        if (coreObject->isList() && toAccessibilityList(coreObject)->isDescriptionList())
> 
> It might be better to introduce a new WebCore role for DescriptionList, but I don't feel that strongly about it

There is a DescriptionListRole already, which in theory should get assigned to any object with the <dl> tag name in determineAccessibilityRole(). Problem is that there is a hardcoded rule in AXObjectCache::createFromRenderer() that creates an instance of AccessibilityList for those elements too:

static PassRefPtr<AccessibilityObject> createFromRenderer(RenderObject* renderer)
{
    // FIXME: How could renderer->node() ever not be an Element?
    Node* node = renderer->node();

    // If the node is aria role="list" or the aria role is empty and its a
    // ul/ol/dl type (it shouldn't be a list if aria says otherwise).
    if (node && ((nodeHasRole(node, "list") || nodeHasRole(node, "directory"))
                      || (nodeHasRole(node, nullAtom) && (node->hasTagName(ulTag) || node->hasTagName(olTag) || node->hasTagName(dlTag)))))
        return AccessibilityList::create(renderer);
   [...]
}

I thought of updating Accessibility::roleValue() to do this isDescriptionList() check and return ListRole or DescriptionListRole accordingly, but I discarded because I was not sure about which things that might break in the Mac, and also because I saw in the Mac wrapper that DescriptionListRole is used in the Mac as a subrole, not a main role, so I was not sure at all about removing the ListRole thing from there.

So, in the end, I went for doing that check in the ATK wrapper, but I'm open to reconsider other options if you think they're feasible.

[Mario Sanchez Prada]

Committed r160712: <http://trac.webkit.org/changeset/160712>

[Mario Sanchez Prada]

(In reply to comment #4)
> Committed r160712: <http://trac.webkit.org/changeset/160712>

I pushed this patch now, but I'm still open to discuss about the DescriptionListRole thing, my previous comment still applies. Just saying :)

[chris fleizach]

(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 219420 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=219420&action=review
> > 
> > > Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp:638
> > > +        if (coreObject->isList() && toAccessibilityList(coreObject)->isDescriptionList())
> > 
> > It might be better to introduce a new WebCore role for DescriptionList, but I don't feel that strongly about it
> 
> There is a DescriptionListRole already, which in theory should get assigned to any object with the <dl> tag name in determineAccessibilityRole(). Problem is that there is a hardcoded rule in AXObjectCache::createFromRenderer() that creates an instance of AccessibilityList for those elements too:
> 
> static PassRefPtr<AccessibilityObject> createFromRenderer(RenderObject* renderer)
> {
>     // FIXME: How could renderer->node() ever not be an Element?
>     Node* node = renderer->node();
> 
>     // If the node is aria role="list" or the aria role is empty and its a
>     // ul/ol/dl type (it shouldn't be a list if aria says otherwise).
>     if (node && ((nodeHasRole(node, "list") || nodeHasRole(node, "directory"))
>                       || (nodeHasRole(node, nullAtom) && (node->hasTagName(ulTag) || node->hasTagName(olTag) || node->hasTagName(dlTag)))))
>         return AccessibilityList::create(renderer);
>    [...]
> }
> 
> I thought of updating Accessibility::roleValue() to do this isDescriptionList() check and return ListRole or DescriptionListRole accordingly, but I discarded because I was not sure about which things that might break in the Mac, and also because I saw in the Mac wrapper that DescriptionListRole is used in the Mac as a subrole, not a main role, so I was not sure at all about removing the ListRole thing from there.
> 
> So, in the end, I went for doing that check in the ATK wrapper, but I'm open to reconsider other options if you think they're feasible.

I think we should go for that route. we may need to update some Mac things but I don't foresee any blockers in that case

[Mario Sanchez Prada]

(In reply to comment #6)
> > I thought of updating Accessibility::roleValue() to do this 
> > isDescriptionList() check and return ListRole or DescriptionListRole 
> > accordingly, but I discarded because I was not sure about which things that 
> > might break in the Mac, and also because I saw in the Mac wrapper that 
> > DescriptionListRole is used in the Mac as a subrole, not a main role, so I 
> > was not sure at all about removing the ListRole thing from there.
> > 
> > So, in the end, I went for doing that check in the ATK wrapper, but I'm open 
> > to reconsider other options if you think they're feasible.
> 
> I think we should go for that route. we may need to update some Mac things but 
> I don't foresee any blockers in that case

See https://bugs.webkit.org/show_bug.cgi?id=126579#c2

[Radar WebKit Bug Importer]

<rdar://problem/15762151>