Describe your concern

It's natural to provide ARIA properties on a custom element and then have the custom element implementation copy that property to a descendant. For example, aria-label, aria-description or aria-placeholder could be provided by the author on the custom element. The custom element would then copy the ARIA properties to the actual input element in its subtree, and it could then place role="none" on the custom element to avoid 1) Having an extra element in the a11y tree with duplicate properties and 2) Using a name on the custom element which likely has a generic role -- name on generic is prohibited.

Currently the role="none" (or role="presentation") on the custom element is ignored because we are afraid of losing the semantics. However, it seems like a reasonable use case to me. I don't think custom elements should get their role="none" markup ignored when used with aria-foo properties. It should still ignore role="none" if it has a tabindex.

Link to the version of the specification or documentation you were looking at at.

https://w3c.github.io/aria

Link to documentation:

https://w3c.github.io/aria/#conflict_resolution_presentation_none

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?

Yes

UPDATE: please see also WICG/webcomponents#1073, to make role="none" the default role for custom elements, except when there is aria-owns or aria-live present, or it is focusable. This is issue is only about allowing role="none" on custom elements at all.