- From: <bugzilla@jessica.w3.org>
- Date: Tue, 08 Oct 2013 03:57:50 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466 --- Comment #6 from Dominic Cooney <dominicc@chromium.org> --- (In reply to James Craig from comment #5) > (In reply to Dominic Cooney from comment #4) > > While I'm NOT the accessibility Dominic, I believe the current thinking is: > > > > - UA can respond to ARIA roles inside Shadow DOM. Component authors who want > > to be "like native" can use this approach. > > There are a few issues with that approach. > > 1. The end result would be an element with a role inside the generic parent > element. If the custom element inherits its role from a native one (like the > dialog example) there is no way to override it, except to tell all authors > to explicitly use role="presentation" on the custom element. Is that a problem? The Custom Element can also set the role attribute in the created callback, without adding additional machinery to the spec for this. > 2. I don't believe focus management for shadow DOM components is fully > specified, which I hope to raise as an issue on that spec, but is > nevertheless a blocker for this suggestion. I think focus management in Shadow DOM is unrelated to Custom Elements. > > - UA responds to ARIA roles on Custom Elements like any element. Authors > > that want to tweak ARIA roles can use this approach. > > This bug was about letting the custom element define its default role so the > author would not have to do this. This was commentary that authors _can_ do this if they want. Note: "can" not "have to". -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 8 October 2013 03:57:52 UTC