Re: Custom Element Semantics

[Alexander Surkov]

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 
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 
> 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.
>>
>> Eat Me
>>
>> * "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
>>

Re: Custom Element Semantics

[Alexander Surkov]

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.

Eat Me

* "The addition of a 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"
 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 
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 
>