1.4.12 Text Spacing and scoped styles with shadow dom

[scottaohara]

I'm at a loss for how 1.4.12 Text Spacing is meant to align with instances of custom elements where their styles are encapsulated by the Shadow DOM, and other styles from the primary document are explicit not supposed to pierce the Shadow DOM to modify the styles of the internals of the custom element.

For example: https://codepen.io/scottohara/pen/xxYWvGj

In that codepen I have a <button> defined in both the light and shadow dom. The styles of the light DOM (where text spacing styles would be enabled by users) do not go into the Shadow DOM, and this is by design.

I can use the Stylus browser plugin and apply text spacing properties to that example, and the button in the light dom adjusts as expected.... and the button in the shadow dom doesn't adjust, which is as I would expect, but I'm not sure what the SC expects here.... and I can bet that users / auditors won't know what to expect here either.

Appreciate thoughts on what can be done here.

[JAWS-test]

The SC only expects all content and functions to be preserved if the spacing is adjustable. The SC does not require that the spacing be adjustable. This is what @patrickhlauke has emphasised here several times.

[scottaohara]

well, would sure be helpful to have that stated somewhere, as I don't think we can just summon Patrick on a whim to explain this to testers/clients/whomever.

Right now, the normative text doesn't call out this stipulation. Nor does the understanding doc. Rather, the understanding doc contains content such as:

If the markup-based technologies being used are capable of overriding text to the Success Criterion's metrics, then this SC is applicable. For instance Cascading Style Sheet/HTML technologies are quite able to allow for the specified spacing metrics.

So the above is unclear in this regard. If CSS/HTML technologies are generally quite able to allow for spacing metrics... except for an instance like this. Can authors then completely get around the SC by including all / most of their content in the Shadow DOM?

[JAWS-test]

What seems decisive to me is how this passage from the understanding is interpreted

Further, this SC is not concerned with how users change the line height and spacing metrics. It does not require that content implement its own mechanisms to allow users to do this. It is not a failure of the content if a user agent or platform does not provide a way for users to do this. Content does not fail this SC if the method chosen by the user - for instance, the use of an extension or bookmarklet - fails to correctly set the line height and spacing text properties on the content (provided that the content is not actively and purposely preventing the properties from being added).

Is using shadow dom "actively and purposely preventing the properties from being added"?

[JAWS-test]

Related: #975 and #884

[JAWS-test]

Shadow dom elements are not images, but they behave like images, i.e. they violate the intention of SC 1.4.5:

The intent of this Success Criterion is to encourage authors, who are using technologies which are capable of achieving their desired default visual presentation, to enable people who require a particular visual presentation of text to be able to adjust the text presentation as needed. This includes people who require the text in a particular font size, foreground and background color, font family, line spacing or alignment.

[GreggVan]

They are also clearly covered by 1.3.1 which requires all Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. gregg

…

On May 31, 2022, at 1:53 PM, JAWS-test ***@***.***> wrote: Shadow dom elements are not images, but they behave like images, i.e. they violate the intention of SC 1.4.5: The intent of this Success Criterion is to encourage authors, who are using technologies which are capable of achieving their desired default visual presentation, to enable people who require a particular visual presentation of text to be able to adjust the text presentation as needed. This includes people who require the text in a particular font size, foreground and background color, font family, line spacing or alignment. — Reply to this email directly, view it on GitHub <#2495 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXVUFE2GSWZBAM3P2SLVMZ357ANCNFSM5XORDOTA>. You are receiving this because you are subscribed to this thread.

[patrickhlauke]

@GreggVan shadow DOM elements can expose their content (and information conveyed through presentation) just fine programmatically / as text. that's orthogonal to the discussion here.

[alastc]

Big picture, it seems like a problem in user-agents if there's no mechanism to over-ride content?

Zoom and text sizing work, but they aren't style over-rides. The plugin I have for font-substitution doesn't work, so I'm assuming that anything attempting to apply styles would fail.

For the SC, I assume there is no means for authors to enable text-spacing for shadow-dom content.

Therefore the bit @JAWS-test highlighted is key:

It is not a failure of the content if a user agent or platform does not provide a way for users to do this.

In the understanding doc we could update the paragraph under "Applicability" to something like:

"If the markup-based technologies being used are capable of overriding text to the Success Criterion's metrics, then this SC is applicable. For instance Cascading Style Sheet/HTML technologies generally allow for the specified spacing metrics."

And add Web Components to the list of items underneath that.