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.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/>
>>>
>>
>>