Re: Custom Element Semantics
Hi, Steve. A second (small) run. * It represents http://www.w3.org/TR/html/dom.html#represents its children. The term represents is defined by Elements in the DOM represent things; that is, they have intrinsic *meaning*, also known as semantics.. So that means that custom elements have meaning of its children, that may sound unclear. For example, a custom element contains text field and button elements so one element represents both a button and a text field. It's questionable how such custom element have to be mapped to accessible tree. Wouldn't it be good to say something like custom element is a container for its children. * All stuff are under 11.1.1 Custom Tag Example. I would describe the idea first and then supplied it by example. For example, As instantiated a custom tag conveys a similar amount of semantics as a HTML div http://www.w3.org/TR/html/grouping-content.html#the-div-element or span http://www.w3.org/TR/html/text-level-semantics.html#the-span-element element doesn't have any need to describe the taco-button example and should be used as generic description. The wording could be like By default a custom tag http://stevefaulkner.github.io/webcomponents/spec/custom/#dfn-custom-tag has no special meaning at all. It serves is a container for its children. As instantiated a custom tag conveys a similar amount of semantics as a HTML div http://www.w3.org/TR/html/grouping-content.html#the-div-element or span http://www.w3.org/TR/html/text-level-semantics.html#the-span-element element. The addition of visual styling and scripted events to the custom element could provide hints as to the semantics and expected interaction behaviours of the custom element for *some* users, but for the semantics to be formally expressed, developers must convey the semantics using ARIA roles http://w3c.github.io/aria/aria/aria.html#usage_intro, states and properties http://w3c.github.io/aria/aria/aria.html#introstates. * The addition of visual styling and scripted events to the custom element could provide hints as to the semantics and expected interaction behaviours of the custom element for *some* users, but for the semantics to be formally expressed, developers must convey the semantics using ARIA roles http://w3c.github.io/aria/aria/aria.html#usage_intro, states and properties http://w3c.github.io/aria/aria/aria.html#introstates It sounds as too strong statement. Scripted events may add semantics and may be mapped to accessible tree, so it's really about some semantics rather than semantics for some users. Also I would replace must for ARIA techniques on can. It's rather a right way to add semantics, but shouldn't be a requirement. Thanks. Alex. On Mon, Dec 15, 2014 at 3:24 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Thanks Alex! I have made some updates to the spec text in response to your feedback, I have also added other content. http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics please review, thanks! -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 9 December 2014 at 17:29, Alexander Surkov surkov.alexan...@gmail.com wrote: Hi. Some feedback per Steve's request on WAI group. * but for the semantics to be formally expressed, developers must convey the role, states and properties of the element to browser APIs. It's not clear what role, states and properties is. It'd be good to develop this sentence by mentioning ARIA techniques. Also it might be not clear what browser APIs are. Perhaps I wouldn't even mention a11y APIs since this info is rather for browser developers and may sound confusing for web authors. * I don't think that any focusable element should get its name from its subtree. For example, tree control name is not a concatenation of subtrees of its item. I think role should define whether the element should grab its name from the subtree or not. taco-button tabindex=0Eat Me/taco-button * The addition of a tabindex http://www.w3.org/TR/html/editing.html#attr-tabindex attribute to the *taco-button* element I think taco-button should be left for examples, but all rules should be worded in generic terms. For example, the sentence above would be The addition of tabindex attribute to the custom element and then give a markup example for taco-button. * The addition of keyboard event handlers to the *taco-button* element provides the means for keyboard users to operate the control, but does not convey the presence of the functionality. I think I miss the idea of this sentence because the topic is about semantics of custom elements and thus it's not clear with me where functionality is supposed to be here. * The addition of an ARIA role=button http://rawgit.com/w3c/aria/master/aria/aria.html#button conveys the *taco-button* element's role semantics It'd be good to generalize it and give this sentence as an example. It'd be good to mention other ARIA button related attributes. Thanks.
Re: Custom Element Semantics
Thanks Alex! I have made some updates to the spec text in response to your feedback, I have also added other content. http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics please review, thanks! -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 9 December 2014 at 17:29, Alexander Surkov surkov.alexan...@gmail.com wrote: Hi. Some feedback per Steve's request on WAI group. * but for the semantics to be formally expressed, developers must convey the role, states and properties of the element to browser APIs. It's not clear what role, states and properties is. It'd be good to develop this sentence by mentioning ARIA techniques. Also it might be not clear what browser APIs are. Perhaps I wouldn't even mention a11y APIs since this info is rather for browser developers and may sound confusing for web authors. * I don't think that any focusable element should get its name from its subtree. For example, tree control name is not a concatenation of subtrees of its item. I think role should define whether the element should grab its name from the subtree or not. taco-button tabindex=0Eat Me/taco-button * The addition of a tabindex http://www.w3.org/TR/html/editing.html#attr-tabindex attribute to the *taco-button* element I think taco-button should be left for examples, but all rules should be worded in generic terms. For example, the sentence above would be The addition of tabindex attribute to the custom element and then give a markup example for taco-button. * The addition of keyboard event handlers to the *taco-button* element provides the means for keyboard users to operate the control, but does not convey the presence of the functionality. I think I miss the idea of this sentence because the topic is about semantics of custom elements and thus it's not clear with me where functionality is supposed to be here. * The addition of an ARIA role=button http://rawgit.com/w3c/aria/master/aria/aria.html#button conveys the *taco-button* element's role semantics It'd be good to generalize it and give this sentence as an example. It'd be good to mention other ARIA button related attributes. Thanks. Alexander. On Tue, Dec 9, 2014 at 4:23 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Hi PF! FYI I have been getting some accessibility related content into the custom elements spec http://w3c.github.io/webcomponents/spec/custom/#semantics please provide feedback on bug https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=14968short_desc=[Custom]%3A%20product=WebAppsWGcomponent=Component%20Model or to webapps list http://lists.w3.org/Archives/Public/public-webapps/ -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
Re: Custom Element Semantics
Hi. Some feedback per Steve's request on WAI group. * but for the semantics to be formally expressed, developers must convey the role, states and properties of the element to browser APIs. It's not clear what role, states and properties is. It'd be good to develop this sentence by mentioning ARIA techniques. Also it might be not clear what browser APIs are. Perhaps I wouldn't even mention a11y APIs since this info is rather for browser developers and may sound confusing for web authors. * I don't think that any focusable element should get its name from its subtree. For example, tree control name is not a concatenation of subtrees of its item. I think role should define whether the element should grab its name from the subtree or not. taco-button tabindex=0Eat Me/taco-button * The addition of a tabindex http://www.w3.org/TR/html/editing.html#attr-tabindex attribute to the *taco-button* element I think taco-button should be left for examples, but all rules should be worded in generic terms. For example, the sentence above would be The addition of tabindex attribute to the custom element and then give a markup example for taco-button. * The addition of keyboard event handlers to the *taco-button* element provides the means for keyboard users to operate the control, but does not convey the presence of the functionality. I think I miss the idea of this sentence because the topic is about semantics of custom elements and thus it's not clear with me where functionality is supposed to be here. * The addition of an ARIA role=button http://rawgit.com/w3c/aria/master/aria/aria.html#button conveys the *taco-button* element's role semantics It'd be good to generalize it and give this sentence as an example. It'd be good to mention other ARIA button related attributes. Thanks. Alexander. On Tue, Dec 9, 2014 at 4:23 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Hi PF! FYI I have been getting some accessibility related content into the custom elements spec http://w3c.github.io/webcomponents/spec/custom/#semantics please provide feedback on bug https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=14968short_desc=[Custom]%3A%20product=WebAppsWGcomponent=Component%20Model or to webapps list http://lists.w3.org/Archives/Public/public-webapps/ -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
