New principle: HTML attributes can affect semantics

[chrishtr]

I think we should consider adding a design principle covering whether HTML element semantics can be affected by an attribute, and if so in what situations. I'm not totally sure how the principle should be stated, so for now this issue is to track a proposed need, and hopefully we can work towards a definition in the issue.

(Note: currently the web platform design principles only refers to semantics for attributes as it relates to choosing names that relate to semantics.)

Two recent features have bearing on this question:

• The popover attribute, which currently defines only behaviors of popovers and has no effect on the semantics of the underlying elements. During spec development, there was guidance not to have it affect element semantics, mostly I believe because that would get very complicated to consider the interaction of popover with the semantics of every HTML element.

• The proposed switch attribute for checkbox inputs. This attribute is proposed to change from a checkbox to a switch, which has somewhat different semantics.

I'm not sure if there are any other examples of HTML attributes affecting semantics.

[annevk]

In my mental model pretty much all HTML attributes impact semantics. So I'm not entirely convinced this is needed. (Except for those that are presentational in nature, such as style.)

[chrishtr]

In my mental model pretty much all HTML attributes impact semantics. So I'm not entirely convinced this is needed. (Except for those that are presentational in nature, such as style.)

@domenic who I think also has thoughts on this discussion.

Ok. Perhaps we should talk more specifically about different applications of the concept of semantics. As it relates to popover and switch, the following two are relevant:

• The effect of HTML attributes on accessibility roles or presence / representation to ATs
  • Example: popover does not affect accessibility roles
  • Example: hidden does, probably also other gobal attributes.
  • Example: images have a different role depending on the alt attribute.
• The effect of HTML attributes on interpretation of an element visually in its surrounding document context
  • Example: the visual display of a switch should affect author guidance for how to position surrounding content (plus some other aspects)

[domenic]

The definition of "semantics" can be slippery and confusing in these discussions. At one extreme, you can use the definition of "what is communicated to anyone" (including developers reading the source code). At the other, you can use the most-practical meaning, of "how are accessibility technology behaviors impacted". So for example, a <section> and an <aside> have different semantics in the first sense, but the same AT behavior. Similarly, arguably <em class="inner-thoughts"> has different semantics compared to <em class="anger">, but again, no impact on AT behavior.

But for HTML attributes in particular, I think that in general many of them don't have meaningful "semantics" in most senses. Attributes are the main customization hook for changing behavior, and we use them as such frequently. Scrolling through https://html.spec.whatwg.org/multipage/indices.html#attributes-3 , some that stick out to me as pretty behavior-focused, where you'd have to really stretch to talk about the impact on semantics:

• accept
• accept-charset
• accesskey
• allow
• async
• blocking
• charset
• decoding
• defer
• draggable
• enctype

... I'll stop there.

[annevk]

But checked impacts AT and visual appearance in pretty much the same way. As does dir, title, or alt (partially depending on whether the image can be fetched). It's certainly true there's a wide variety of attributes, but I don't think popover or switch are particularly novel.