Re: Custom Elements: is=""

My current understanding of "is=" is a request for an implementation to "plug-in" a native element's backing behavior under a custom element name. This feature would otherwise not be available without is=, as custom elements are always generic by design.

As Dimitri has noted in the past, I think this feature nicely solves some accessibility gaps in the platform. It's not ideal, but I believe it is useful. I'm not wedded to the syntax or API for doing this though, and I'd welcome suggestions to improve it.

________________________________________
From: Ryosuke Niwa <rniwa@apple.com>
Sent: Monday, June 8, 2015 5:58 PM
To: Alice Boxhall
Cc: Anne van Kesteren; Léonie Watson; WebApps WG
Subject: Re: Custom Elements: is=""

> On Jun 8, 2015, at 4:37 PM, Alice Boxhall <aboxhall@google.com> wrote:
>
>
>
> On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>>> On Jun 8, 2015, at 3:23 PM, Alice Boxhall <aboxhall@google.com> wrote:
>>>
>>> On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>>>
>>>> > On Jun 8, 2015, at 2:16 PM, Alice Boxhall <aboxhall@google.com> wrote:
>>>> Web developers are already writing their own "custom elements" as a bunch of nested div's.  How does introducing custom elements make it worse?
>>>
>>> I believe the rest of my comment already addressed this.
>>
>> Sorry, I don't follow.
>>
>>>> >> - I realise that to some extent developers already aren't using native elements, in part because of the styling issues we've discussed which also affect is=. My concern here is that custom elements will further legitimise this habit, which we've been making some recent progress in changing - we stand to backslide on that effort. Having is= would allow us to roll it into the "use native elements where possible" message rather than diluting it with "unless you're using a custom element in which case here's a checklist which you're not going to look at of everything it should do" until we come up with an alternative.
>>>>
>>>> In the case of stylizing elements, it doesn't really matter if authors attach a shadow DOM on top of a builtin input element or to a div because as soon as the shadow DOM replaces the rendered contents, we can't make assumptions about how to expose that element to AT.
>>>
>>> That's simply not true at all. If someone replaces the rendered content of a `<button>`, we know that their intent is to create an element which is semantically a button, and may even be rendered as a button in some cases. Similarly for `<input>` with a `type` attribute. This is no different to using an ARIA role as far as assistive technology is concerned.
>>
>> Perhaps I should have said "we can't _always_ make assumptions about how to expose that element to AT."
>>
>> Consider creating a date picker in the time we haven't added type=date yet.  Inside the shadow DOM of this color picker may contain various buttons and controls to move between months and pick a date.  Treating the entire control as a text field will provide a very poor user experience.
>
> Ah, I see what you're saying now, thanks for clarifying.
>
> In this case, the custom element author can add semantic markup inside Shadow DOM just as the browser does for a date picker currently - no assumptions need to be made, since even in the case of type extensions the Shadow DOM is available to the accessibility tree. I don't think it will ever treat the entire control as a text field.

If you're fine with that, why don't you just let authors just put ARIA role in buttons' shadow DOM as well?

It would also mean that the author must override the ARIA role implicitly set (text field) by UA in this case.  I'd say that's exactly the kind of "feature" that makes the Web platform annoying.

>> All the use cases I can think of that let UA can safely make assumptions about the ARIA role of the element involves tweaking the appearance, which is better served by better styling mechanisms for form controls.
>>
> I don't think it's an either/or question between is= and styling mechanisms for form controls. I actually think we need both.

Why?  Having authors use two completely different mechanisms to define semantics seems like the worst of the both worlds.

- R. Niwa

Received on Tuesday, 9 June 2015 05:42:52 UTC