- From: Aaron Leventhal <notifications@github.com>
- Date: Wed, 25 Sep 2024 11:53:03 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1073@github.com>
It's natural (and possibly common) for component implementations to copy ARIA properties from the custom element and then have the custom element implementation copy that property to a focusable descendant. For example, aria-label, aria-description or aria-placeholder could be provided by the author on the custom element. The custom element would then copy the ARIA properties to the actual input element in its subtree. This is problematic because it would cause there to be duplicated properties on 2 objects in the a11y tree, which could lead to duplicate announcements or other strange behaviors in assistive technologies. For example, a screen reader like JAWS or NVDA with virtual buffer navigation would have two objects with the same label or description. Unfortunately this pattern is already out there, and that means many many actual usages of the custom elements are already doing it. At this point it's too hard to get people to stop doing the pattern. I appeal to the community to come up with creative solutions. I added an issue to the ARIA to allow role=none to be set on the custom element to remove it from the a11y tree (currently the spec/browsers require role=none to be ignored on elements that also have global ARIA attributes). Here's the issue I filed: https://github.com/w3c/aria/issues/2303 It could make sense to have a default role of none on custom elements (e.g. if there is no other role set). Do people think that this will cause backwards compatibility issues? I suppose it would fix the problem, so, it would be good to know if anyone foresees an issue with that. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1073 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1073@github.com>
Received on Wednesday, 25 September 2024 18:53:07 UTC