Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 6:43 PM, Domenic Denicola <d@domenic.me> wrote:

> 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:eoconnor@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
>
>

I think you really need look no further than HTML as Custom Elements work
to see how difficult it would be to get accessibility right even if we had
good APIs, which, as Domenic pointed out, we really don't.

Anyway, it seems like one of the biggest criticisms we have seen of custom
elements anyone has made has to do with accessibility... It definitely
doesn't seem desirable to make it *harder* to get that right if we can
avoid it, because this could definitely play into the success or failure
story writ large.



-- 
Brian Kardell :: @briankardell :: hitchjs.com