Created attachment 441857 [details] A reduced test case When a parent element with an AXLabel contains an empty element, Voice Over announces the parent element as empty group. Since the role "none" is not mapped to the accessibility APII and is synonymous with the role "presentation," the parent element in the condition described before should not be announced as "group."
<rdar://problem/84453056>
https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/#conflict_resolution_presentation_none > User agents MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics. However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied. aria-label is a global property, so WebKit must expose the given element. It's called a group because applying an aria-label to an element with a role of "presentation" or "none" hits this branch in AccessibilityNodeObject::determineAriaRoleAttribute(): // Presentational roles are invalidated by the presence of ARIA attributes. if (role == AccessibilityRole::Presentational && supportsARIAAttributes()) role = AccessibilityRole::Unknown; And at the callsite of determineAriaRoleAttribute, AccessibilityRole::Unknown falls back to determining the role by the tag name (AccessibilityRole::Div), which maps to NSAccessibilityGroup on the Mac. The behavior in this branch is maybe unintuitive, but I don't know the "right" thing to do without digging deeper.
The problem is not that it shouldn't expose the elements, but that they are announced as empty groups by VO. The user experience I would expect here is that in the three cases, VO announces the presence of a video element, with a label in cases 1 and 2, and no label in case 3.