+1 to errata: „any of“ or even „any of the following alone or in combination“. If only it wasn‘t so cumbersome.

As an aside, we have been wondering whether it is makes sense to specify a default screen with for testing text spacing, or whether testing implies covering all potential viewport widths and page states on those views. Sometimes issues only appear in drop-down menus and other stuff, so it is rather laborious to test.

+1 to any

As an aside, we have been wondering whether it is makes sense to specify a default screen with for testing text spacing, or whether testing implies covering all potential viewport widths and page states on those views.

I'd be tempted to say that this applies to (and needs to be tested at) all screen sizes (with, for sanity, 320 CSS px width / 256 CSS px height as a common sense lower limit), though yes this is very laborious to test, agree. if the site has dimension-based breakpoints, testing needs to happen at each breakpoint at least, but any size in between would also theoretically need testing, IMO.

if the site has dimension-based breakpoints, testing needs to happen at each breakpoint at least, but any size in between would also theoretically need testing

Yes, according to WCAG 2.1: 5.2.2 Full pages: "A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform"

@alastc is it worth making a PR here that changes the normative wording for an errata version?

Given that it's a one-word change, that's enough to survey.

My (chair-hat-off) opinion:

this may be misinterpreted as meaning that it only applies when all four properties (line height, spacing following paragraphs, letter spacing, word spacing) are set by the user.

Does it matter? If it is tested by setting all of them, that is going to provide the most change, the most likely way to break a layout.

Is it worth increasing the test-overhead by testing them individually and together? That would be 4+3+2+1 = 10 combinations (if my school-level maths is correct).

to me it's about plugging gaps that people may find by interpreting the exact wording of SCs to then later argue about whether or not something passes or fails. for testing, i'd still end up testing it together for expediency / in the knowledge that it's unlikely a site would fail for only one vs all of them. but then if later on it's found that a site did fail when only changing a particular combination, it's not a "yes but the SC normatively says it's only when all of them are changed", but more "oh ok, this was missed out in testing, but yes it fails"

That is how I would approach it, but it sounds risky in the 3rd party auditor context, at least in the US.

Is it worth increasing the test-overhead by testing them individually and together? That would be 4+3+2+1 = 10 combinations

theoretically there are not 10 test cases, but infinitely many, because I would have to test all possible distances between standard and maximum value as well ("to at least") and furthermore at all screen widths

because I would have to test all possible distances between standard and maximum value as well

Not from the SC text as it is now, which is to set all of them to the particular values.

@alastc

I understand "to at least" in 1.4.12 that all intermediate values must also work, such as with SC 1.4.4 also all zoom levels up to 200%. In contrast to 1.4.10, where exactly 320px are required and no intermediate levels.

From memory, the "to at least" means you can go above those values, but you should test to 'at least' those values.

It assumes that if it works at those values then it will work at lower values, but doesn't require testing of that.

Draft response based on discussion today (mainly @mbgower's comment):

The SC was written to make testing straight forward for a pass: set these 4 qualities to these levels, and you pass this SC.

While there may be some scenarios where one of these alone would cause a failure where all of them did not, that is clearly an outside case, the intent was to make it straightforward & efficient.

shame that, as with similar discussions around "up to" on the reflow SC a ages ago, ease of testing/preventing unforeseen liability for auditors takes precedence. but fair enough.

@patrickhlauke - I think it is about practical deference to the skill set of an average well-intentioned developer who is best served by very concrete okay, this is working requirement to assess against. Now, you might presume that the person authoring the page should know from their source code that setting any of the four variables will work (or not), and will work for the full range of the specified values. But I don't think the average developer has that sort of insight into the behavior of borrowed source code they are using but probably did not develop from scratch. Auditors facing legal liability are very small subset of our audience.

Noting a couple of concerns here for posterity sake. The current approach is reasonable when considering needs across the spectrum, including those of developers, but it would be helpful to document the following:

1. It is possible to fail with just one and pass with all four. Given that different individuals have different preferences, we do a disservice to a user when they may have a preference for just one thing to change. Changing all four parameters requires significantly more technical savvy and time than changing just one (e.g., font size is a common preference that can easily be set in a user's browser preferences, but line height is often much more difficult to set). In the future, we may want to consider documenting the difference between making things work with standard browser settings vs. with specialized AT. Ultimately, though, the user shouldn't have to be expected to change all parameters to get something to work right for them. That is a large burden on the individual user.
2. I think it is important to make sure our language doesn't imply that we are prioritizing the needs of the testers over the needs of the users. It is easy to do this accidentally, but clearly both needs are important. If we decided to keep the word "all" instead of "any," I would at least suggest re-examining the nuance of the language. Perhaps something like, "The SC was written to guide testing: set these 4 qualities to these levels, and you pass this SC."

@rainbreaw that is a good observation that it is possible to fail 1.4.12 with just one setting (not working). But I think I am missing something. What do you mean by pass with all four? Of course you pass with all four!

In the context of this particular SC, I don't think changing all to any changes the normative requirement! The bullets already include at least so the implication is clear that the full range is required.

While I agree that setting the four qualities to the levels specified should be a sufficient test for passing this SC, the SC text requires more than that. The guidance that set these 4 qualities to these levels, and you pass this SC could be part of an evaluation/testing script, but it is not a 100% paraphrase of the requirement.

The bullets already include at least so the implication is clear that the full range is required. [...] it is not a 100% paraphrase of the requirement.

@bruce-usab based on the discussion that was had on this, and @alastc's response

While there may be some scenarios where one of these alone would cause a failure where all of them did not, that is clearly an outside case, the intent was to make it straightforward & efficient.

so normatively the only case where this fails is if you set "all of the following" to "at least" those specified values. if you set only one of those, and leave the others alone, or you set them all to values below the ones specified, and things fail ... but through cunning an author managed to catch just the exact case normatively specified, it would fail for users, but would not fail the SC.

i.e. say my page passes when setting all four properties to those specified values, but my styles do fall apart if only line height is changed to 1.5, then it normatively passes.

yes those cases may be rare. but depending on how styles are set up, they could happen.

for what it's worth, i made an admittedly contrived case where a script checks for one of these precise values (at the time we were discussing the "up to" / lower boundary case) https://codepen.io/patrickhlauke/full/jgVGOp - this same approach could be extended to only check for the exact 4 properties to be set to the specified values, and only kick in to "fix" the page in those cases, but break otherwise. this again would pass the SC but possibly fail users that don't set all four properties to those specified values.

Thank you @patrickhlauke for adding the additional context on the conversation about the words "any" vs. "all."

@alastc it's trivial, but as i just stumbled across it: was this ever surveyed?

Argh, just lost what was a pretty long and explicit draft response to this!

Short summary (probably better for everyone):

• the idea of "user" language in the SC is introduced in the issue; "user" is not in the normative wording. This is directed at the author, based on documented user need from LVTF (and I believe COGA as well). This SC could potentially benefit users who also vary other text attributes; it was not intended to (nor does it as far as I can see) place burden on users, nor require them to change text settings.
• "All" was intentional. It greatly reduces testing burden for authors/testers/auditors with no apparent negative impact on user. Since all 4 properties increase text spacing, it is highly unlikely many edge cases exist where one property failure would be resolved by all four properties being increased. @rainbreaw and @patrickhlauke can you produce examples? I haven't seen any examples surfaced since 2.1 came out
• if we do identify some cases, that can then lead to a discussion/assessment by the working group on potential changes, where we weigh impact on user versus impact from requirement (i.e., benefit versus increases in normative complexity/testing burden)
• Similar reasoning for setting a threshhold to test at. If a page can pass with these all set at these levels, it goes a long way to addressing user need. If we find evidence that the single test case results in unforeseen failures at lower levels, we can assess and reconsider.

One possible action in response to this issue is to add material to the Understanding document to make this all more explicit.

the idea of "user" language in the SC is introduced in the issue; "user" is not in the normative wording. This is directed at the author

well, to be more precise: the author must allow for the text spacing metrics to be changed without adverse effect. but it's the user (via the user agent) that overrides/sets these spacing metrics, not the author...

can you produce examples? I haven't seen any examples surfaced since 2.1 came out

don't have one in the wild, but as mentioned previously:

for what it's worth, i made an admittedly contrived case where a script checks for one of these precise values (at the time we were discussing the "up to" / lower boundary case) https://codepen.io/patrickhlauke/full/jgVGOp - this same approach could be extended to only check for the exact 4 properties to be set to the specified values, and only kick in to "fix" the page in those cases, but break otherwise. this again would pass the SC but possibly fail users that don't set all four properties to those specified values.

@patrickhlauke asked if this was surveyed. Yes. From the 25 May 2021 minutes:

RESOLUTION: The intent of the SC was to set all 4 simultaneously. We will not change, and we will review the proposed response at a later date.

@bruce-usab a good good. so then this can be closed (a drop in the ocean of open issues, but still)