Re: [w3c/webcomponents] accessibility considerations: states and behaviors (#567)

Also, I might have been a bit brief here, assuming that you could grok my entire thought process from that link. Let me expand a bit.

I totally agree with the overall goal of making custom elements able to behave the same way as built-ins. You may have seen my earlier work on that in https://github.com/domenic/html-as-custom-elements which has some thoughts on accessibility as well.

However, I think it's important to get there in the way that makes the most sense, which I think (per the extensible web manifesto) is to expose the same low-level APIs, like the accessibility tree, that browsers use to create the built-ins. This can then be imperatively manipulated by JavaScript code (similar to the C++ backing the built-ins).

We already have one declarative way of achieving these accessibility characteristics and the related behaviors: the is attribute. It has its own restrictions due to its declarative nature. We should not build another declarative way, with new restrictions (e.g. being restricted to CSS selector matching). Instead we should go imperative and allow full freedom.

That said, there might be room for some very basic declarative APIs to cover the 80% case. E.g. I think @dominiccooney has a proposal that simply allows setting the default role and tabIndex. This gives you the ability to emulate some of the built-ins, but not all (e.g. the a element changes its role depending on the presence of the href attribute). I'm not sure whether that's worth it compared to just using the is attribute. But maybe it's reasonable as a stopgap until we are ready to expose the accessibility tree.

-- 
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/567#issuecomment-247062714