{"action":"opened","issue":{"url":"https://api.github.com/repos/hayatoito/test/issues/282","labels_url":"https://api.github.com/repos/hayatoito/test/issues/282/labels{/name}","comments_url":"https://api.github.com/repos/hayatoito/test/issues/282/comments","events_url":"https://api.github.com/repos/hayatoito/test/issues/282/events","html_url":"https://github.com/hayatoito/test/issues/282","id":92604236,"number":282,"title":"[Accessibility]: Custom element should allow declaration of default accessibility features, such as role and other ARIA attributes. (bugzilla: 20466)","user":{"login":"hayatoito","id":160288,"avatar_url":"https://avatars.githubusercontent.com/u/160288?v=3","gravatar_id":"","url":"https://api.github.com/users/hayatoito","html_url":"https://github.com/hayatoito","followers_url":"https://api.github.com/users/hayatoito/followers","following_url":"https://api.github.com/users/hayatoito/following{/other_user}","gists_url":"https://api.github.com/users/hayatoito/gists{/gist_id}","starred_url":"https://api.github.com/users/hayatoito/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hayatoito/subscriptions","organizations_url":"https://api.github.com/users/hayatoito/orgs","repos_url":"https://api.github.com/users/hayatoito/repos","events_url":"https://api.github.com/users/hayatoito/events{/privacy}","received_events_url":"https://api.github.com/users/hayatoito/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-07-02T10:24:27Z","updated_at":"2015-07-02T10:24:27Z","closed_at":null,"body":"Title: [Accessibility]: Custom element should allow declaration of default accessibility features, such as role and other ARIA attributes. (bugzilla: 20466)\n\nMigrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466\n\n----\ncomment: 0\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c0\n*James Craig* wrote on 2012-12-20 20:19:01 +0000.\n\nProbably needs to be done declaratively on the container rather than in the ShadowDOM content template, as this should be available in the DOM.\n\n\\<element extends=\"dialog\" role=\"alertdialog\" name=\"x-alert\" constructor=\"AlertDialog\">\n    …\n\\</element\\>\n\nExample:\n$ new AlertDialog().outerHTML\n> \\<dialog is=\"x-alert\" role=\"alertdialog\">…\\</dialog\\>\n\n----\n\ncomment: 1\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c1\n*Dominic Cooney* wrote on 2012-12-21 06:59:49 +0000.\n\nI think this is a good idea.\n\nDoes it make sense to have a default set of attributes and values, and simply piggyback accessibility defaults on that mechanism?\n\n----\n\ncomment: 2\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c2\n*Dominic Cooney* wrote on 2013-06-06 02:13:02 +0000.\n\nI think that this has been languishing under the wrong bug--this is a Custom Elements spec question.\n\n----\n\ncomment: 3\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c3\n*Dimitri Glazkov* wrote on 2013-10-08 02:38:40 +0000.\n\nJames, 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.\n\nFWIW, I certainly do not want to build something that magically sets attributes on an element at the construction time.\n\nDominic (the Accessibility one), I remember you talking about this for custom elements or shadow trees? I thought you guys had a good reasonable solution?\n\nI would really like to move default ARIA roles problem over to the next iteration and get the spec to LC.\n\n----\n\ncomment: 4\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c4\n*Dominic Cooney* wrote on 2013-10-08 02:44:39 +0000.\n\nWhile I'm NOT the accessibility Dominic, I believe the current thinking is:\n\n- UA can respond to ARIA roles inside Shadow DOM. Component authors who want to be \"like native\" can use this approach.\n\n- UA responds to ARIA roles on Custom Elements like any element. Authors that want to tweak ARIA roles can use this approach.\n\n- There's an issue with the default value of tabindex, but it is related to Shadow DOM, not Custom Elements.\n\nSo I don't think there's anything for the Custom Elements spec here. This bug should be closed.\n\n----\n\ncomment: 5\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c5\n*James Craig* wrote on 2013-10-08 03:36:27 +0000.\n\n(In reply to Dominic Cooney from comment #4)\n> While I'm NOT the accessibility Dominic, I believe the current thinking is:\n> \n> - UA can respond to ARIA roles inside Shadow DOM. Component authors who want\n> to be \"like native\" can use this approach.\n\nThere are a few issues with that approach. \n\n1. 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. \n\n2. 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.\n\n> - UA responds to ARIA roles on Custom Elements like any element. Authors\n> that want to tweak ARIA roles can use this approach.\n\nThis bug was about letting the custom element define its default role so the author would not have to do this.\n\n----\n\ncomment: 6\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c6\n*Dominic Cooney* wrote on 2013-10-08 03:57:50 +0000.\n\n(In reply to James Craig from comment #5)\n> (In reply to Dominic Cooney from comment #4)\n> > While I'm NOT the accessibility Dominic, I believe the current thinking is:\n> > \n> > - UA can respond to ARIA roles inside Shadow DOM. Component authors who want\n> > to be \"like native\" can use this approach.\n> \n> There are a few issues with that approach. \n> \n> 1. The end result would be an element with a role inside the generic parent\n> element. If the custom element inherits its role from a native one (like the\n> dialog example) there is no way to override it, except to tell all authors\n> to explicitly use role=\"presentation\" on the custom element. \n\nIs that a problem?\n\nThe Custom Element can also set the role attribute in the created callback, without adding additional machinery to the spec for this.\n\n> 2. I don't believe focus management for shadow DOM components is fully\n> specified, which I hope to raise as an issue on that spec, but is\n> nevertheless a blocker for this suggestion.\n\nI think focus management in Shadow DOM is unrelated to Custom Elements.\n\n> > - UA responds to ARIA roles on Custom Elements like any element. Authors\n> > that want to tweak ARIA roles can use this approach.\n> \n> This bug was about letting the custom element define its default role so the\n> author would not have to do this.\n\nThis was commentary that authors _can_ do this if they want. Note: \"can\" not \"have to\".\n\n----\n\ncomment: 7\ncomment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c7\n*James Craig* wrote on 2013-10-08 06:40:59 +0000.\n\n(In reply to Dominic Cooney from comment #6)\n> (In reply to James Craig from comment #5)\n> > (In reply to Dominic Cooney from comment #4)\n> > > While I'm NOT the accessibility Dominic, I believe the current thinking is:\n> > > \n> > > - UA can respond to ARIA roles inside Shadow DOM. Component authors who want\n> > > to be \"like native\" can use this approach.\n> > \n> > There are a few issues with that approach. \n> > \n> > 1. The end result would be an element with a role inside the generic parent\n> > element. If the custom element inherits its role from a native one (like the\n> > dialog example) there is no way to override it, except to tell all authors\n> > to explicitly use role=\"presentation\" on the custom element. \n> \n> Is that a problem?\n\nSorry, 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. \n\nThe 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. \n\n\n> The Custom Element can also set the role attribute in the created callback,\n> without adding additional machinery to the spec for this.\n\nPerhaps I'm misunderstanding. Are you saying my example would work as-is?\n\n\\<element extends=\"dialog\" role=\"alertdialog\" name=\"x-alert\" constructor=\"AlertDialog\">\n    …\n\\</element\\>\n\nOr are you saying the element author should use something like this.setAttribute('role', 'alertdialog'); in the custom element's constructor?\n\nOr 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.\n\n> > 2. I don't believe focus management for shadow DOM components is fully\n> > specified, which I hope to raise as an issue on that spec, but is\n> > nevertheless a blocker for this suggestion.\n> \n> I think focus management in Shadow DOM is unrelated to Custom Elements.\n\nI 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."}}