[Webkit-unassigned] [Bug 283049] AX: VoiceOver ignores descendant elements of any separator element

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Nov 16 13:26:35 PST 2024


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

Tyler Wilcock <tyler_w at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tyler_w at apple.com

--- Comment #2 from Tyler Wilcock <tyler_w at apple.com> ---
Hi Marc! This part of the spec says:

https://www.w3.org/TR/wai-aria-1.2/#childrenArePresentational

> Presentational Children
> Values
> Boolean (true | false)
> The DOM descendants are presentational. User agents SHOULD NOT expose descendants of this element through the platform accessibility API. If user agents do not hide the descendant nodes, some information may be read twice.
Despite using the word "presentational", this is different than role="none" / role="presentation", which does operate as you state:

https://w3c.github.io/aria/#none

> For any element with a role of none/presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element (the role and its states and properties) to accessibility APIs. However, the user agent MUST expose content and descendant elements that do not have an explicit or inherited role of none/presentation. Thus, the none/presentation role causes a given element to be treated as having no role or to be removed from the accessibility tree, but does not cause the content contained within the element to be removed from the accessibility tree.
So based on these bits, it seems like WebKit is behaving correctly (besides maybe iOS VoiceOver not stopping on splitters). Do you agree with that? If so, the wording of "Presentational Children" certainly could be better to avoid this confusion — could be worth filing a spec issue.

Regarding aria-label not being read on role="separator": it does seem like that should work — maybe we can file a separate bug to track that independent of this other issue.

-- 
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/20241116/735f56b7/attachment.htm>


More information about the webkit-unassigned mailing list