- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Thu, 29 Jan 2015 11:48:02 -0800
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
- Message-id: <95FC3A34-E62D-4E92-B966-6E486DF25F86@apple.com>
> On Jan 29, 2015, at 7:52 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote: > On 29 January 2015 at 15:37, Anne van Kesteren <annevk@annevk.nl <mailto:annevk@annevk.nl>> wrote: > I don't have enough technical understanding to know what is viable or not, > you and others are saying that the current accessibility feature support > baked in to custom elements spec via is= is not acceptable > > That seems rather disingenuous. > > where am I being disingenuous? > > I don't understand how the various pieces are pulled together to make an element work in browsers to an extent to be able to offer possible technical solutions. If I did I would. I think there is a bit of miscommunication here. Correct me if I'm wrong but I think you're trying to fix the problem of Web developers writing their own UI widgets and components and they're often inaccessible because they didn't set ARIA roles right, etc… If that's the problem you're trying to solve here, then what you need is shadow DOM, not custom elements. As someone who cares about accessibility deeply, I want to solve this problem too. However, like Anne pointed out in earlier threads, authors aren't going to start using custom elements to implement those fancy UI widgets currently implemented via div's and span's using is=~ attribute since custom elements doesn't provide any mechanism to change the appearance of a builtin element. Shadow DOM, on the other hand, is one proposed mechanism to replace the appearance of a builtin element by way of replacing the contents of the element via a shadow tree. Now, if we're using shadow DOM to change the appearance of a builtin element, then choosing which appearance to use in the HTML markup via a content attribute is a layering violation. We should be doing that in CSS instead. And we have a proposal to do both of these things: decorators [1] One more thing. I would really like if we could stop making claims such as web components as currently spec'ed magically improves accessibility because it's doing a huge disservice to the future of the Web accessibility. They don't. Far from it. I've pointed out numerous issues with them over the last couple of years but none of them have been adequately addressed. [1] https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html#decorator-section - R. Niwa
Received on Thursday, 29 January 2015 19:48:31 UTC