It's natural to provide ARIA properties on a custom element and then have the custom element implementation copy that property to a descendant. For example, aria-label, aria-description or aria-placeholder may be provided by the author using a custom element. The custom element's implementation often copies ARIA properties to another element, where the properties are now duplicated. This is a problem for two reasons: 1. Properties duplicated between 2 different elements can cause redundant announcements or otherwise confuse assistive tech operating on the a11y tree. 2) Using an accessible name via aria-label* on the custom element currently will have a generic role by default causes a violation of ARIA spec rules that accessible names are prohibited for role="generic". Currently, browsers ignore this rule, which will cause the accessible name to be announced twice by screen readers. This feature addresses the issue by removing custom elements from the a11y tree, except when: - A role is provided on the custom element - The custom element is itself focusable - It uses aria-live (legit use case) or aria-owns (must remain in tree) Spec issues: https://github.com/w3c/aria/issues/2303 https://github.com/WICG/webcomponents/issues/1073 Chromium CLs: https://chromium-review.googlesource.com/c/chromium/src/+/5894644 https://chromium-review.googlesource.com/c/chromium/src/+/5894749
As explained in the summary, this will help avoid double announcements in screen readers when authors use a common pattern of copying ARIA properties from custom elements to elements in their shadow tree.
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
No milestones specified