From @goodwitch on April 4, 2018 17:48

+1 to specifying these as discrete tests (we must be pragmatic)

glenda sims | team a11y lead | deque.com | 512.963.3773
web for everyone. web on everything. - w3 goals

[image: IAAP International Association of Accessibility Professionals:
Certified Professional in Accessibility Core Competencies (CPACC)]
http://www.accessibilityassociation.org/certification

On Wed, Apr 4, 2018 at 12:46 PM, David MacDonald notifications@github.com
wrote:

Making orientation work 320 pixels is tough, and then when text size
maximums are added it compounds the requirements.

If the site has to work at 320px and then is turned on its landscape on
the phone, sticky headers that have vertical media queries for anything
over 320 pixels on sticky headers will often cause clipping. Then compound
with the increase text and paragraph and line spacing, even the best sites
have trouble. For example I was mess up evaluating Nomensa for
implementation and although careful work had been done to meet 1.4.10
reflow, when these two other factors were applied at that size content was
clipped and could not be accessed.

We may want to specify these as discrete tests, rather than compound SCs?
???

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
w3c/wcag21#850, or mute the thread
https://github.com/notifications/unsubscribe-auth/AH0uWj67vvbWpI-_54OJr12Fj8h3MIUoks5tlQbYgaJpZM4THOJ4
.

From @mbgower on April 4, 2018 23:43

I found similar issues, and was also wondering about cumulative requirements. These two in particular are a bit odd because larger text is kerned a bit tighter for readability -- so text spacing may be less of a consideration with enlarged type. I'd like to hear from the LVTF on this.

Another consideration emerged for 2.0 Contrast (Minimum) requirements, in situations where text appears over a background image. Nomensa took great care to darken the image where the text was positioned over top, but either Reflow or Text Spacing moved the positioning of text. COMBINED they can really push text into much lighter parts of the image. A takeway was that text on variable contrast backgrounds is going to be much more likely to fail with 2.1.

From @guyhickling on April 9, 2018 20:40

From a tester's point of view I agree each of these tests should be tested in isolation. Otherwise the testing becomes unmanageable.

It also allows too much uncertainty. If it is decided that certain SCs should be tested together at the same time, then there should be another SC to state that those particular items must be able to work together, so developers and testers would all know where they stand. (Or amend one of the SCs to say it must apply in conjunction with another.) No one should be left to wonder "should I test these together at the same time". A definite instruction should be stated somewhere.

On the original question, however, I don't see that adding a Reflow test to the Orientation test is a valid thing to do. The Reflow SC is not about mobile devices in spite of its wording. It is all about low vision users 400% zooming on their desktop PC. They cannot switch between a "vertical" and "landscape" view. Low vision users will most likely be using all or most of the screen estate available to them to see as much as possible of the large text in one go. So the Orientation SC (which is for mobiles) does not need to be tested in conjunction with the Reflow SC.

Incidentally, there are no tests in the Reflow SC Understanding document yet. But when they are devised, they should be tests that are specified for running at 400% on a desktop PC; they shouldn't be tests on a mobile, as that does not always achieve the same results as 400% zoom.

From @mraccess77 on April 10, 2018 0:36

Today SC like 1.4.3 Contrast and zoom have to be tested together because zoom can change contrast of text when backgrounds change. If SC were tested separately then I could have 1 keyboard accessible page and 1 sufficient contrast page and 1 screen reader friendly page -- that is not the direction WCAG should be supporting. In this particular situation you mention we end up with some requirements that could be tricky -- so my recommendation is that if it is not achievable then we should be clear to say that these two or three don't need to be tested together but all others do.

From @lauracarlson on April 10, 2018 12:30

Hi @guyhickling

You wrote:

Incidentally, there are no tests in the Reflow SC Understanding document yet. But when they are devised, they should be tests that are specified for running at 400% on a desktop PC; they shouldn't be tests on a mobile, as that does not always achieve the same results as 400% zoom.

A draft Allowing for Reflow technique is in the wiki along with a draft Allowing for Spacing Override technique.

From @jake-abma on April 11, 2018 17:45

Understand the isolation part and from a gut feeling agree, just to be 100% clear in testing and not clutter possibilities to test with too many variables. Also @mraccess77 has a valid point about 1.4.3. and Zoom but the approach should not be to see it as "tested together" in my opinion.

Preferably I see it as "all variations of a web page should be tested for each SC", and as Zoom is all about different variations of the same page, all of the SC apply.

From @guyhickling on April 11, 2018 18:19

Yes, @mraccess77 is exactly right about zoom needing to be tested with the contrast SC, that's a long known case where 2 SCs should be looked at together. But as @jake-abma says, that does not usually apply (I think probably in the majority of cases it doesn't).

So my thought is that, especially as we are now adding so many new SCs which developers and testers/auditors alike will be unfamiliar with, it ought to be stated somewhere which ones must be tested with which others. Otherwise some people will not think of testing together when they should or vice versa, and others simply won't know what to do. I guess the Understanding documents should make that clear in each case where two or more SCs should be tested at the same time - for instance in the Understanding docs for 1.4.12 Text Spacing and the Reflow SC.

The Testing section in an Understanding would be the right place state it, as in, for instance, "This SC should be tested in conjunction with SCN.N.N". Then everyone will know exactly where they stand.

From @alastc on April 25, 2018 11:38

I don't see an issue with orientation? Whether a site blocks changing orientation doesn't seem to impact the sizing aspects. As we've used a small portrait-width as the minimum width for reflow, switching to landscape only increases the width available. (If the display changes width, which it does for responsive sites, but not for static width sites.)

It does decrease height, obviously, but so long as it has scrolling in one direction that doesn't impact the SC pass/fail.

For text-spacing and reflow, we do have text in the doc that says it applies across screensize variations:

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.

We do have text in some understanding docs that points out where SCs intersect, I think a review of Reflow & text-spacing with that in mind is in order.

From @guyhickling on April 25, 2018 12:24

We do have text in some understanding docs that points out where SCs intersect, I think a review of Reflow & text-spacing with that in mind is in order.

Yes, that should fit the bill for those two SCs. (The text you also quoted is there, but way down at the end of the document so most people will miss it.)

More generally, where any two SCs interact, if the Testing section in both SCs mention that testing must also be done in conjunction with the other SC, that should cover it. E.g. "This success criterion should be tested in conjunction with success criterion N.N.N" and perhaps a bit more to say why in each case. I am not familiar enough with how GitHub branches and changes are done to join in on making changes or I would!

Incidentally, going back to the Contrast and 200% text size SCs that @mraccess77 mentioned above, I have just taken a quick look through their Understanding docs and neither of them make any reference to the other. Which probably goes some way to explaining why developers don't think of that possibility and why many websites fail on that point when text size increases. Although it's not part of this project since they are both WCAG 2.0, they could both do with a Notes adding to mention the point. I don't know what the procedure is for suggesting Notes for 2.0?

From @alastc on April 25, 2018 13:48

There isn't generally a "testing section" in understanding documents as the test methods are outlined in the techniques. There is probably some understandable confusion about that at the moment because (pre-techniques being created) some of the new docs do have information about testing.

We can take a similar approach to the non-text contrast understanding, which outlines it's relation to Use of Color. (It also has a 'Testing princples' section, but if there is a suitable technique for that, it should be moved out of the doc.)

I'd like to move this into individual understanding doc issues, are there additions needed to these?

• In text-spacing understanding, add a note that it should be tested across media queries (as per the conformance text).
• In Color contrast (text, minumum) understanding, add a note that it should be tested across media queries (as per the conformance text).
• Non-text contrast, add a note that it should be tested across media queries (as per the conformance text), e.g. some icons will not have associated text at smaller screen sizes / greater zoom.

Any others?

I need to find out about updates to WCAG 2.0 docs, as they remain in 'TR' space which has certain publishing requirements, it will probably take longer.

From @WayneEDick on April 25, 2018 16:24

The fixed header problem is serious, and easily fixed. One can also test
height the second parameter of resolution. At low resolutions, if it height
is less than width then set headers to scroll. I do it all the time in
stylish. From the outside perspective it is difficult finding a selector
for the heading, but the author could do this easily.

Spacing and font-size are related. This is of no concern to the author. The
user must choose spacing to fit font size. Users usually start with very
big font (zoom) then they add spacing and find they can live with
significantly smaller font-size.

So, most of the cumulative effects must be resolved by user choices.

Wayne

On Wed, Apr 4, 2018 at 4:43 PM, Mike Gower notifications@github.com wrote:

I found similar issues, and was also wondering about cumulative
requirements. These two in particular are a bit odd because larger text is
kerned a bit tighter for readability -- so text spacing may be less of a
consideration with enlarged type. I'd like to hear from the LVTF on this.

Another consideration emerged for 2.0 Contrast (Minimum) requirements, in
situations where text appears over a background image. Nomensa took great
care to darken the image where the text was positioned over top, but either
Reflow or Text Spacing moved the positioning of text. COMBINED they can
really push text into much lighter parts of the image. A takeway was that
text on variable contrast backgrounds is going to be much more likely to
fail with 2.1.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
w3c/wcag21#850 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0OF4g8MJgz1uOPCdQMNsLxekmmvjM8ks5tlVqhgaJpZM4THOJ4
.

From @lauracarlson on April 25, 2018 16:53

Hi Alastair and all,

On Wed, Apr 25, 2018, 8:48 AM Alastair Campbell notifications@github.com
wrote:

• In text-spacing understanding, add a note that it should be tested
  across media queries (as per the conformance text).

I would tend to think that would be more appropriate in techniques. For
example the draft technique already says:
"Where a page has multiple layouts (e.g. in a responsive design) text
spacing should be tested in each layout."

https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override

Thoughts?

Laura

From @alastc on April 26, 2018 22:50

Hi Laura,

You're right, I just meant that we add these cross-SC references to the Github issue for each understanding doc. They should be dealt with in techniques, but until we have those to attach them to, I don't want to loose this.

Or we could tag this with 'techniques' and leave it until next week.

-Alastair

From @lauracarlson on April 26, 2018 23:16

Hi Alastair,

+1 to tagging "technique" and dealing with them in the appropriate type of
document.

Some of the understanding docs are verbose enough now without adding
testing details to them.

However, it may make sense to add the name of a "Future technique" to the
technique section of the understanding docs that don't already have a draft
technique like text spacing already has.

Thanks.

On Thu, Apr 26, 2018, 5:50 PM Alastair Campbell notifications@github.com
wrote:

Hi Laura,

You're right, I just meant that we add these cross-SC references to the
Github issue for each understanding doc. They should be dealt with in
techniques, but until we have those to attach them to, I don't want to
loose this.

Or we could tag this with 'techniques' and leave it until next week.

-Alastair

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
w3c/wcag21#850 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AF7TkNzWEmXGUa1Upkxck3Cei0ZEBhcvks5tsk8ZgaJpZM4THOJ4
.

From @DavidMacDonald on April 27, 2018 16:34

I'm not sure this thread is still addressing the original issue... Does WCAG 2.1 require new SCs to cumulatively pass... does 1.4.10 not pass unless it passes AFTER the maximum text spacing is implemented AND the page orientation is set to Landscape?

That is 2x more difficult to meet than 1.4.10 BEFORE text spacing and Orientation are considered.
We don't have this type of cumulative effect of SCs in WCAG 2.0 that I can think of.

My though is that each SC passes on its own merits from a "standing position".

From @mraccess77 on April 27, 2018 16:56

@DavidMacDonald wrote My though is that each SC passes on its own merits from a "standing position".

I can't agree to this as a blanket statement -- in particular as it relates to SC 1.4.4 and 1.4.3. This is also contradicts our statement that was added to the CR section around variations on pages.

From @alastc on April 28, 2018 0:24

does 1.4.10 not pass unless it passes AFTER the maximum text spacing is implemented AND the page orientation is set to Landscape?

We have that new conformance text that means each SC should pass in the page's different versions, including layout-changes due to screen width.

I don't see how orientation affects this. It increases the width available, but shouldn't be different from desktop zoom in this regard.

For text-spacing, yes, that should apply at the different zoom levels as per the conformance text.

I suggested a combined 1.4.4 / 1.4.10 / 1.4.12 test process here.

Unless there's something normative to suggest otherwise?

From @DavidMacDonald on May 1, 2018 16:22

Summarize ... Orientation SC requires that the page is not locked, not that all functionality works.

From @DavidMacDonald on May 1, 2018 17:3

Here's my understanding of our discussion May 1st meeting

1. the intention is that orientation that the content is not locked. We need to define in the Understanding what we mean by "view" and "operation".
2. Zoom 1.4.4 can rely on pinch zoom on mobile devices. So at smaller breakpoints checking that Pinch works will continue to be how to test, even in light of Reflow
3. Reflow should work with text spacing at maximum ???
4. Ensuring that each SC works at each Break point is a big consideration which we have to discuss, to ensure we didn't just quadruple testing work.

From @guyhickling on May 1, 2018 18:13

I wasn't at the above meeting so don't know what was said but I have a couple of thoughts. On (1) above, from the Orientation SC, it seems to me the words:

not restrict its view and operation to a single display orientation

simply mean it can be "displayed in either orientation as opposed to deliberately restricting the display to only one orientation". Does that help?

(2) I am not sure why media breakpoints are being mentioned in connection with pinch zoom. Pinch zoom simply expands the whole content smoothly. Breakpoints don't come into it. They are for adjusting the content to the size of screen, whereas pinch zoom takes over within that screen.

The prime concern for SC1.4.4 when applied to mobile phones is that zoom should be allowed - zoom should not be prevented by the developer having wrong values in the viewport meta tag. If that happens I report it under 1.4.4.

(3) I am in favour, I think, of applying Reflow in conjunction with maximum text spacing. I am sure some people will have larger spacing as well as larger text size, and would find things difficult if websites did not allow that without corrupting the display. But I was very interested in Wayne's comment above of his observation of some users:

Users usually start with very big font (zoom) then they add spacing and find they can live with significantly smaller font-size.

From @mraccess77 on May 1, 2018 20:33

@DavidMacDonald wrote "2. Zoom 1.4.4 can rely on pinch zoom on mobile devices. So at smaller breakpoints checking that Pinch works will continue to be how to test, even in light of Reflow"

On mobile yes -- but I'd argue that just testing this on mobile doesn't prove it's accessibility supported by different user agents. Unless it's a mobile only site you'd need to test for 200% zoom on each breakpoint on the desktop as well because people with low vision who use browser zoom trigger these breakpoints on desktop. More issues are likely to occur there in my opinion.

From @alastc on May 1, 2018 23:36

Hi @DavidMacDonald,

I think Guy is generally on the money with his interpretations:

1. the intention is that orientation that the content is not locked. We need to define in the Understanding what we mean by "view" and "operation".

That's my understanding. You could imply from the SC text that if something disappears in a different orientation you can't operate it, but it is stretching past the intent which we should clarify in the understanding.

2. (Zoom) text-sizing 1.4.4 can rely on pinch zoom on mobile devices. So at smaller breakpoints checking that Pinch works will continue to be how to test, even in light of Reflow

Reflow is orthogonal to mobile browsers, it is a content requirement not a user agent requirement. If the UA supports some kind of zoom (like pinch-zoom) don't disable it (except above 200%).

@mraccess77 wrote:

Unless it's a mobile only site you'd need to test for 200% zoom on each breakpoint on the desktop as well because people with low vision who use browser zoom trigger these breakpoints on desktop.

I don't get the 200% zoom per breakpoint thing, if you are in one breakpoint (e.g. >1000px), and zoom 200% you would likely be in a different breakpoint (e.g. >500px) as you've zoomed.

The test for 1.4.4 & 1.4.10 needs to include:

• Desktop zoom down to 320px
• Check the text-size at least doubles at that point, and if not then, at some in-between point.
• Check the text-size can be doubled in a mobile device.

NB: Pinch-zoom is not AT any more than desktop (browser) zoom is, otherwise it would zoom the chrome of the browser as well as the content.

3. Reflow should work with text spacing at maximum ???

Taking a step back, I'd say that text-spacing should work across the breakpoints the site provides, up to a maximum of 320px. If the site isn't responsive, you can still pass/fail text-spacing. If you provide breakpoints, then as per the conformance note you should test text-spacing across them (which, theoretically, we should have been doing already).

4. Ensuring that each SC works at each Break point is a big consideration which we have to discuss, to ensure we didn't just quadruple testing work.

If we did, it was with the conformance note, not due to a particular SC.

For some we do (should) call out where things can change. For example if an interface removes text next to an icon at smaller screen size, that should then be covered by non-text contrast where it isn't at larger sizes.

Like Patrick, we have been testing across screen sizes (but do need to tighten up on that), there are particular SCs where it can make a difference, and primarily the ones for/from low-vision. Text size, contrast, spacing...

From @mraccess77 on May 2, 2018 0:13

@alastc wrote • Desktop zoom down to 320px
• Check the text-size at least doubles at that point, and if not then, at some in-between point.
• Check the text-size can be doubled in a mobile device.

I understand that and that covers the SC.

But the reason I said that 200% would need to be tested at each breakpoint on desktop is because we added the WCAG conformance note saying that all criteria had to be tested at each variation with each SC. So when we added that note are now saying test 200% for each variation. At least that is how I would read that note. Perhaps you read it differently but there lies the issue.

From @alastc on May 2, 2018 7:48

But the reason I said that 200% would need to be tested at each breakpoint on desktop is because we added the WCAG conformance note saying that all criteria had to be tested at each variation with each SC.

But when zoom is the mechanism (for many UAs) for getting to 200%, that doesn't make sense.

Even if you do read it that way, it could be fulfilled by methods such as pinch zoom. But that doesn't really make any progress for anyone.

We have two main categories of UA / layout:

1. Desktop (style) browsers which have zoom with reflow, and will have windows sizes from 1024 upwards.
2. Mobile (style) browsers which do not (generally) have a reflow method, with screen sizes upto around 1366px (iPad pro 12.9 landscape).

Therefore the tests I suggested above do cover that SC including the note, because if you have reflow then you have at least a starting point of 1024. Even with a window that is 800 or 640 wide you can 'test' upto 200% text size (via zoom) from that starting point.

From @WayneEDick on May 29, 2018 0:44

Hi Everyone,

I propose the following text of conformance. Set spacing to the max
allowable values. For each orientation, run the page through every
breakpoint. If it fails at any breakpoint it the page fails.

More exactly: Max spacing factors are the maximum spacing allowed by
Text-Spacing: Max_LS=0.12 (line spacing), Max_WS=0.16 (word spacing),
MaxLH=1.5 (line height), Max_PS=2 (paragraph trailing spaces).

Each of these parameters are factors multiplied by the local font-sizes
taken from author's design choices. If the authors running font is 16px
then the letter spacing will be (0.12)(16) px, for a 10px. A 10px subscript
will become (0.12)(10) px. We need to respect this because the author needs
font-size variability to support break-points and normal size conventions.
What is critical to understand for zoom is that the pixel sizes will be in
CSS pixels. A running text of 16px at 100%, will be 16 CSS px at 400% zoom.

Testing Combined SCs Reflow and Text-Spacing

1: Set letter-spacing to Max_LS, word-spacing to Max_WS, line-height to
Max_LH, paragraph spacing to Max_PS. W denote the resolution width at 100%

2: for Orientation in [portrait, landscape] {

   3: Zoom = 100% to W/320 or W/256 // as needed {

          4: Check Functionality

   }

}

Check Functionality (Zoom, BRF)

Definition: Base Reading Font. At 100% enlargement, the font size of the
primary font used for reading is the Base Reading Font (BRF)- typesetters
call this the base font. It is measured in pixels.

1: All interactive elements are usable.

2: All text reflows including text in table cells.

3: Horizontal scrolling is restricted to exceptions.

4: The main content is visible and not obscured by excessively large fixed
position objects for headings, footings and asides.

5. If X = the Base Font Size in pixels and Y = the size of the
   corresponding font in CSS pixels, then X=Y.

Number 5. requires a little explanation. Authors may vary font size from
breakpoint to breakpoint. The main example is header size with lower
resolution. An h1 that is 150% of the Base Reading Font will be way too big
with lower resolution. It makes sense to make headings smaller as
resolution goes down. It makes no sense to make the reading text smaller.
This will probably not be a problem for experienced developers, because
they will know that nobody wants to read a page if the reading font is too
small. An inexperienced developer might try to rig reflow by making reading
font smaller at breakpoints. 5 is meant to keep developers from "tripping
on their shoe laces".

Well that's how I perceive it.

Wayne

From @mraccess77 on May 29, 2018 19:4

@alastc that helps to clarify. We'll definitely need some guidance to help people measure. For example, with a responsive site you may have to check font values to make sure they are 2x. If the font values don't change then you would need to check the scale factor of the page 200% keeping in mind that at 200% some content may have gotten larger by media queries and other by scale. Measure all of the important text on the page an tracking it could be tricky. The onresize event might be helpful for writing a favlet to assist people with this.

From @WayneEDick on May 29, 2018 20:52

I am confused. There are two sizing SCs. The old Resize Text and the new Reflow. Are we saying that a site that only provides 200% enlargement when the resolution is 320 CSS pixels will suffice.

Specifically, if on my machine I enlarge Chrome until it hits 400% enlargement, and in fact my resolution is not 320px then my actual text enlargement for running text could only be 200%? Would that pass?

Wayne

Ported from w3c/wcag21#850 but incomplete.

I have folks saying that the SC don't need to be tested at the same time because the understanding documents don't say we need to. It seems like we have consensus on text spacing and 320CSS -- is it just a matter of updating the understanding document for each SC?

more generally...authors could well change all sorts of things at different breakpoints (including colors, content order, even javascript-based functionality). while reflow/text size/orientation are kind of related, it really is more a matter of convenience in testing that we'd generally end up testing those three aspects in the same testing step. but really, on a more general level, auditors should be testing ALL success criteria at ALL possible sizes/breakpoints/aspect ratios, no? (but probably having 320 CSS px width as a reasonable lower limit, as things do really require very specific adaptations/changes once you go much smaller than that, from a purely practical point of view).

To @mraccess77:

"...folks saying that the SC don't need to be tested at the same time because the understanding documents don't say we need to"

I don't think anyone can argue with that. If the WCAG doesn't say so, how can we expect people to do it? We arrived at a wording in #850 last May just before release that specifically says otherwise. It was, "Other SCs such as text-spacing and colour contrast should be tested in each page variation." But so far as I can see that was never included in the released WCAG.

So until that wording or something like it is included, perhaps in the Understanding documents for the Text Spacing and Colour Contrast SCs, I don't see how we can back up that SCs should be tested together if someone quite rightly says "the WCAG doesn't ask for it". Many people are only interested in conforming strictly to the specification without doing anything further (and it's good that they are willing to come that far).

@patrickhlauke

auditors should be testing ALL success criteria at ALL possible sizes/breakpoints/aspect ratios

Please don't take us down that route! If there are three media breakpoints that would almost triple the time to test everything. A very large corporation with lots of test teams might be able to manage that (though I doubt if they would). But auditors, especially external independent consultants, have to charge for their time. If one person tried to charge three times the amount to cover that level of testing they would simply lose the business to someone else who didn't do that.

Please don't take us down that route!

well sorry, but it's true. unless you audit only a specific size and then explicitly state that your audit results are only valid for that particular size.

what if a site passes all relevant A/AA SCs at 1920x1080 browser size, but as soon as the user makes the window any smaller, colors get changed to completely non-contrasty versions, content gets shuffled around into completely meaningless order, visible focus is removed, etc... do you just smile and say the site is a-ok ?

@guyhickling the note added to the WCAG conformance requirements in WCAG 2.1 already requires that each automatic variation conform to WCAG. So at some level the different responsive variations have to be tested. This is critical because I run into RWD when I use zoom on the desktop and anyone who uses smaller screens will run into those variations.

in fact, that note (part of 5.2.2 Full Page) is actually quite lenient, as it only mentions different screen sizes. conceptually. there are even more variations that can occur (and should really be tested for) if we'd factor in things like user agent sniffing (e.g. changing layout/functionality in the page for a specific browser/device) or feature detection (e.g. checking if it "looks" like a touch-capable device and doing things like removing focus outlines, keyboard event listeners, etc). generally, we try to find out about this sort of thing from the client if possible, rather than having to actively "hunt" for these situations though...but again, to do a thorough job, these sorts of automated variations (based on things that a user doesn't have direct control over) still count...

Trying to wrap up old issues, is this proposed response still agreeable?

The Success Criteria (SC) are not cumulative. However, there is a conformance requirement that each designed variation of a page (including breakpoints) should be tested for each SC.

As browser-zoom is used by people to increase the text size, and this zooming can result in variations of the page due to media query breakpoints being triggered, it is not necessary to then test different text-sizes (for SC1.4.4) across the variations of the page. Any of the variations created by breakpoints can fullfil the text sizing requirement. Other SCs such as text-spacing and color contrast should be tested in each page variation.

I'm not very keen on the idea of splashing "you must test this across page variations" on most understanding docs, is a normative ref in the doc enough?

I'm not very keen on the idea of splashing "you must test this across page variations" on most understanding docs, is a normative ref in the doc enough?

would a note in https://www.w3.org/TR/WCAG21/#cc2 work (it implicitly already says this - since to claim that "Each of these variations needs to conform" means actually testing the variation against all SCs)

The WG agreed the response above, so closing this issue.

The note in cc2 does already say what is meant, if anyone wishes to update understanding docs, please submit a PR or doc outlining the update.