- From: Ryosuke Niwa <notifications@github.com>
- Date: Sat, 05 Nov 2016 00:39:34 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
Received on Saturday, 5 November 2016 07:40:06 UTC
Right, that was one of the arguments we made to argue against `is`. Progressive enhancement based on `is` sounds nice in theory but in practice, any app that relies on JS / DOM "enhancements" made by *customized builtin* code would break. Similarly, anytime a shadow root is attached on a builtin element, we can't simply assume the ARIA role of the underlying element. For example, imagine input's `type=date` didn't exist and we were building it as a customized builtin element. Then by attaching a shadow root on `input` (which is not even allowed in shadow DOM API at the moment), and introducing controls for changing months, etc... in the shadow tree, we're effectively rewriting the semantics that needs to be communicated with the assistive technology. So, in practice, user agents would need to use the *flat tree* to construct the accessibility tree anyway except all but the simplest of the simplest case. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/509#issuecomment-258596646
Received on Saturday, 5 November 2016 07:40:06 UTC