I think this is a good idea.

Does it make sense to have a default set of attributes and values, and simply piggyback accessibility defaults on that mechanism?

I think that this has been languishing under the wrong bug--this is a Custom Elements spec question.

James, since there is no declarative syntax in this iteration (level?) of the spec, I had assumed that it's not in scope, at least for the moment.

FWIW, I certainly do not want to build something that magically sets attributes on an element at the construction time.

Dominic (the Accessibility one), I remember you talking about this for custom elements or shadow trees? I thought you guys had a good reasonable solution?

I would really like to move default ARIA roles problem over to the next iteration and get the spec to LC.

While I'm NOT the accessibility Dominic, I believe the current thinking is:

- UA can respond to ARIA roles inside Shadow DOM. Component authors who want to be "like native" can use this approach.

- UA responds to ARIA roles on Custom Elements like any element. Authors that want to tweak ARIA roles can use this approach.

- There's an issue with the default value of tabindex, but it is related to Shadow DOM, not Custom Elements.

So I don't think there's anything for the Custom Elements spec here. This bug should be closed.

(In reply to Dominic Cooney from comment #4)
> While I'm NOT the accessibility Dominic, I believe the current thinking is:
> 
> - UA can respond to ARIA roles inside Shadow DOM. Component authors who want
> to be "like native" can use this approach.

There are a few issues with that approach. 

1. The end result would be an element with a role inside the generic parent element. If the custom element inherits its role from a native one (like the dialog example) there is no way to override it, except to tell all authors to explicitly use role="presentation" on the custom element. 

2. I don't believe focus management for shadow DOM components is fully specified, which I hope to raise as an issue on that spec, but is nevertheless a blocker for this suggestion.

> - UA responds to ARIA roles on Custom Elements like any element. Authors
> that want to tweak ARIA roles can use this approach.

This bug was about letting the custom element define its default role so the author would not have to do this.

(In reply to James Craig from comment #5)
> (In reply to Dominic Cooney from comment #4)
> > While I'm NOT the accessibility Dominic, I believe the current thinking is:
> > 
> > - UA can respond to ARIA roles inside Shadow DOM. Component authors who want
> > to be "like native" can use this approach.
> 
> There are a few issues with that approach. 
> 
> 1. The end result would be an element with a role inside the generic parent
> element. If the custom element inherits its role from a native one (like the
> dialog example) there is no way to override it, except to tell all authors
> to explicitly use role="presentation" on the custom element. 

Is that a problem?

The Custom Element can also set the role attribute in the created callback, without adding additional machinery to the spec for this.

> 2. I don't believe focus management for shadow DOM components is fully
> specified, which I hope to raise as an issue on that spec, but is
> nevertheless a blocker for this suggestion.

I think focus management in Shadow DOM is unrelated to Custom Elements.

> > - UA responds to ARIA roles on Custom Elements like any element. Authors
> > that want to tweak ARIA roles can use this approach.
> 
> This bug was about letting the custom element define its default role so the
> author would not have to do this.

This was commentary that authors _can_ do this if they want. Note: "can" not "have to".

(In reply to Dominic Cooney from comment #6)
> (In reply to James Craig from comment #5)
> > (In reply to Dominic Cooney from comment #4)
> > > While I'm NOT the accessibility Dominic, I believe the current thinking is:
> > > 
> > > - UA can respond to ARIA roles inside Shadow DOM. Component authors who want
> > > to be "like native" can use this approach.
> > 
> > There are a few issues with that approach. 
> > 
> > 1. The end result would be an element with a role inside the generic parent
> > element. If the custom element inherits its role from a native one (like the
> > dialog example) there is no way to override it, except to tell all authors
> > to explicitly use role="presentation" on the custom element. 
> 
> Is that a problem?

Sorry, each instance is unique and I did not clearly describe the scenario. Imagine an the site's lead engineers set up a set of custom element for non-technical content providers to use. 

The implication was that it some cases, it would be necessary to override the role, and therefore forcing each user of the tag <x-alert> to include role attribute and other related markup would be unacceptable, flaky, and defeat some of the purpose of using a custom element that should be including all of its own semantics and functionality. 


> The Custom Element can also set the role attribute in the created callback,
> without adding additional machinery to the spec for this.

Perhaps I'm misunderstanding. Are you saying my example would work as-is?

<element extends="dialog" role="alertdialog" name="x-alert" constructor="AlertDialog">
    …
</element>

Or are you saying the element author should use something like this.setAttribute('role', 'alertdialog'); in the custom element's constructor?

Or something else entirely? Thanks for clarifying. If this type of thing can indeed already be done, then all I'd request is an editorial note or example in the spec stating how that can and should be achieved.

> > 2. I don't believe focus management for shadow DOM components is fully
> > specified, which I hope to raise as an issue on that spec, but is
> > nevertheless a blocker for this suggestion.
> 
> I think focus management in Shadow DOM is unrelated to Custom Elements.

I agree, but it's valid to point out why your suggestion of using the shadow DOM would not yet work in some cases, and therefore should not be used as justification for dismissing this bug.

Moved to https://github.com/w3c/webcomponents/issues/159