- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Tue, 16 Dec 2014 12:11:31 -0500
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
- Message-ID: <CA+epNse9z+rcMaWsLekrPhsQStyaYJTm+VEb_WfjdS+fZMXh=g@mail.gmail.com>
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.steve@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.alexander@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="0">Eat 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.steve@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=14968&short_desc=[Custom]%3A%20&product=WebAppsWG&component=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/> >>> >> >>
Received on Tuesday, 16 December 2014 17:12:03 UTC