Steve's concerns are best illustrated with a more complicated element like <button>. He did a great pull request to the custom elements spec that contrasts all the work you have to do with <taco-button> vs. <button is="tequila-button">:
https://w3c.github.io/webcomponents/spec/custom/#custom-tag-example vs. https://w3c.github.io/webcomponents/spec/custom/#type-extension-example The summary is that you *can* duplicate *some* of the semantics and accessibility properties of a built-in element when doing custom tags, but it's quite arduous. (And, it has minor undesirable side effects, such as new DOM attributes which can be overwritten, whereas native role semantics are baked in.) Additionally, in some cases you *can't* duplicate the semantics and accessibility: https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md#incomplete-mitigation-strategies An easy example is that you can never get a screen reader to announce <custom-p> as a paragraph, while it will happily do so for <p is="custom-p">. This is because there is no ARIA role for paragraphs that you could set in the createdCallback of your CustomP. However, this second point is IMO just a gap in the capabilities of ARIA that should be addressed. If we could assume it will be addressed on the same timeline as custom elements being implemented (seems ... not impossible), that still leaves the concern about having to duplicate all the functionality of a button, e.g. keyboard support, focus support, reaction to the presence/absence of the disabled attribute, etc. -----Original Message----- From: Edward O'Connor [mailto:eocon...@apple.com] Sent: Thursday, January 15, 2015 18:33 To: WebApps WG Subject: Re: Minimum viable custom elements Hi all, Steve wrote: >> [I]t also does not address subclassing normal elements. Again, while >> that seems desirable > > Given that subclassing normal elements is the easiest and most robust > method (for developers) of implementing semantics[1] and interaction > support necessary for accessibility I would suggest it is undesirable > to punt on it. Apologies in advance, Steve, if I'm missing something obvious. I probably am. I've been writing an article about turtles and I've gotten to the point that six levels of headings aren't enough. I want to use a seventh-level heading element in this article, but HTML only has h1–6. Currently, without custom elements, I can do this: <div role=heading aria-level=7>Cuora amboinensis, the southeast Asian box turtle</div> Suppose instead that TedHaitchSeven is a subclass of HTMLElement and I've registered it as <ted-h7>. In its constructor or createdCallback or whatever, I add appropriate role and aria-level attributes. Now I can write this: <ted-h7>Cuora amboinensis, the southeast Asian box turtle</ted-h7> This is just as accessible as the <div> was, but is considerably more straightforward to use. So yay custom elements! If I wanted to use is="" to do this, I guess I could write: <h1 is=ted-h7>Cuora amboinensis, the southeast Asian box turtle</h1> How is this easier? How is this more robust? I think maybe you could say this is more robust (if not easier) because, in a browser with JavaScript disabled, AT would see an <h1>. <h1> is at least a heading, if not one of the right level. But in such a browser the <div> example above is even better, because AT would see both that the element is a heading and it would also see the correct level. OK, so let's work around the wrong-heading-level-when-JS-is-disabled problem by explicitly overriding <h1>'s implicit heading level: <h1 is=ted-h7 aria-level=7>Cuora amboinensis, the southeast Asian box turtle</h1> I guess this is OK, but seeing aria-level=7 on and <h1> rubs me the wrong way even if it's not technically wrong, and I don't see how this is easier or more robust than the other options. Thanks, Ted
