[Webkit-unassigned] [Bug 231914] AX: Any addition of children should funnel through AccessibilityObject::addChild

[bugzilla-daemon at webkit.org]

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

--- Comment #13 from Tyler Wilcock <tyler_w at apple.com> ---
(In reply to chris fleizach from comment #12)
> Comment on attachment 441675 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=441675&action=review
> 
> > Source/WebCore/accessibility/AccessibilityObject.cpp:-518
> > -        ASSERT(child->parentObject() == this);
> 
> do we still want this parent object assert too?
Yeah, spoke to Andres and we think this ASSERT might not be that useful in its current form, since it is often verifying DOM parent-child relationship rather than AX tree parent-child relationships. There are several cases where DOM parent-child relationships are validly not how the AX tree is structured (i.e. aria-owns, tables, autofill buttons). I'm just going to remove it.

> > Source/WebCore/accessibility/AccessibilityTableRow.cpp:155
> > +    if (ariaOwnedElements.size()) {
> 
> this size check seems unnecessary now
That would be a change in behavior from the current:

Either add "aria-owns" elements as m_children, _or_ AccessibilityRenderObject::addChildren() (aka DOM children) as m_children.

Your suggestion would be unconditionally adding both aria-owns children and DOM children to m_children.

Based on the definition of aria-owns (https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/#aria-owns), your suggestion seems right.

> If an element has both aria-owns and DOM children then the order of the child elements with respect to the parent/child relationship is the DOM children first, then the elements referenced in aria-owns.
But I think I'd rather make that behavior change in a separate patch, since other classes do the same thing.

-- 
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/20211019/b46a5471/attachment.htm>