Skip to content

Get clarity/agreement on what is meant by a Note 3 of 5.2.2 Full page conformance #4294

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mbgower opened this issue Mar 21, 2025 · 10 comments

Comments

@mbgower
Copy link
Contributor

mbgower commented Mar 21, 2025

As noted in #1522 (comment) the WCAG 2 Task Force discussion about text resizing and zoom revealed some questions about Note 3 of 5.2.2 Full pages conformance, which reads:

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.

My position would be that in the context of discussing conformance of a full page, this note is referring explicitly to break points (i.e., the "automatic" transformation of the page through media queries to accommodate a new form factor). This is considered a new page because the page layout has been intentionally altered to accommodate differences in the physical screen dimensions (i.e., aspect ratios) of different form factors (either physical devices or emulators of that screen size).

It was suggested during discussion that any use of zoom would constitute a "variation of the page". That if a browser's zoom function is used to go from 100% to 110% it would constitute a new variation according to 5.2.2, even if this change did not trigger a break point.

However it is clear to me on review that the phrase "each variation of the page" cannot be taken alone, separate from the qualifying clause that follows it. Full page conformance is not assessed by any variation in the page. It is assessed for a "variation of the page that is automatically presented by the page for various screen sizes".

First, I would like to find out if there is general agreement on this position.
Second, I would like to find out if anyone believes this needs better documentation, either via an alteration of the informative note, or in an information document (Understanding or Technique).

@patrickhlauke
Copy link
Member

patrickhlauke commented Mar 21, 2025

As mentioned in the call, I strongly disagree that 5.2.2 is only relating to breakpoints. Moreover, with the exception of a few specific SCs, we don't have any qualifiers anywhere that say anything along the lines of "this SC applies only at this one particular browser/viewport size". In theory, each SC applies in all situations, regardless of what size of viewport the user has.

We don't go around saying "this site passes WCAG 2.2, but only if the user has their browser set to 1920 by 1080 at 100% zoom". SCs must hold true at (theoretically) any viewport size, meaning at any zoom setting or resized browser window.

@patrickhlauke
Copy link
Member

If we want to split hairs, zooming/resizing the browser window may not create "variations" in the breakpoint sense - fine, but then it means it's still the same variation/page, so it must still satisfy all SCs regardless of its viewport size. otherwise, you would need to clarify explicitly when the page passes (at a viewport size of X by Y)

@patrickhlauke
Copy link
Member

turning this around, nowhere in WCAG does it say that SCs don't apply to certain browser/viewport sizes - hence, SCs apply to all browser/viewport sizes

Then 5.2.2 specifies that if there's variations that happen (because of breakpoints in CSS, or some JavaScript kicking in, or whatever), then those must also then be taken into account.

@mraccess77
Copy link

I agree with Patrick - if I have a lower resolution set that may trigger page variations or layout changes. Maybe I have a different language and get a language variation. Even if not - WCAG applies to the whole page regardless of whether I use a fluid layout and don't use media queries.

@patrickhlauke
Copy link
Member

Also, just adding here for clarity: all of the above is referring to full-page zoom (and not text-only resizing or similar), as full-page zoom has the exact same outcome/effect as resizing the browser window, in that both modify the size of the viewport. As WCAG doesn't say "SCs must only be satisfied at this particular window/viewport size" (with a few very specific examples when they do, like for reflow), it logically follows that (in theory at least) SCs must be satisfied at any window/viewport size (if you want to call each a "variant", or just the same page, is probably academic)

@mbgower
Copy link
Contributor Author

mbgower commented Mar 28, 2025

I feel like there is a separate discussion being brought here, which is orthogonal to the originating issue, so let me just focus on that nuance. Here is the germane note from the Resize text Understanding document:

As with most other Success Criteria, this criterion applies to each variation of the page that is automatically presented for various screen sizes (e.g. media query variations in a responsive site). In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement in order to satisfy the criterion.

For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280 CSS pixels wide, at 200% zoom it will visually appear at twice the size. After zooming by 400% the page reflows to fit within the 320 CSS pixel viewport, the author may decide to set the page's text size to 10px. The text is now half the original size in CSS pixels, but as it has been enlarged to 400%, it is still displayed at twice the size compared to the default browser setting at 100% zoom. It is not required to achieve 200% text enlargement while remaining inside a specific breakpoint (as zooming may result in the variation for a new breakpoint becoming active), but it should still be possible to get 200% text enlargement in some way compared to the default 100% zoom.

If you are going to make the argument that every magnification of the page represents a new variation, then we have a problem: a 'variation' with a 1% increase in zoom, itself needs to have text be 10% larger, which causes a new variation, which in turn will need to be 10% larger, etc. The resize requirement MUST be based on a stable baseline, and in our definition of Page, that is measured from the starting presentation. We then have a note that clarifies that other designed break points content as separate page baselines. You'll also note that even within that measure, there is a caveat on how 200% is interpreted.

@mraccess77
Copy link

At each zoom level 110, 120 I think the page would need to comply. The SC says up to 200%. SC 1.4.4 is about the default size - so I do not see that as as a problem as it's not comparing is each variation for that SC.

@patrickhlauke
Copy link
Member

If you are going to make the argument that every magnification of the page represents a new variation, then we have a problem: a 'variation' with a 1% increase in zoom, itself needs to have text be 10% larger, which causes a new variation, which in turn will need to be 10% larger, etc. The resize requirement MUST be based on a stable baseline, and in our definition of Page, that is measured from the starting presentation.

but starting presentation doesn't specify a particular browser window size / viewport size. it cannot, as we can't guarantee every user will have the same. and different viewport size is exactly what happens when you also full-page zoom.

if a user runs their browser at, say, a window/viewport size of 640x480 for some reason, then they should still be able to increase text by 200%. it's irrelevant that that viewport size is already what happens if the user was running their browser at 1280x960 and zoomed to 200%.

text resize has always been a problem child, because it has no anchoring and is from a time before browser zoom (which also changes the actual viewport size in CSS pixels) was even a thing.

@patrickhlauke
Copy link
Member

patrickhlauke commented Mar 28, 2025

for the "potentially that means infinite zooming must be possible" aspect, that's exactly the discussion we already had many times in the past (when i suggested having a "sensible" lower limit for the SC)

in modern browsers resize text really means (assuming that we're all agreed that full-page zoom is a valid way to satisfy the SC): the user must be able to zoom continuously - exactly because yes, you could say "200% from whatever the 100% is", but 100% by itself is meaningless since it doesn't also define "a browser window at this specific width and height, and zoomed to 100%".

@patrickhlauke
Copy link
Member

patrickhlauke commented Mar 28, 2025

full-page zooming = changing viewport size. and SCs need to apply/pass regardless of viewport size (as nowhere in WCAG, with a few key exceptions like Reflow, does it specify that SCs only apply at a specific size). and yes, in the context of Resize Text, this leads to a potential infinite zooming chain (which should be addressed normatively, ideally, or at least as a note in the understanding, defining some kind of "sensible" lower bound beyond which content can't be expected to be further zoomed - generally, user agents set a limit here anyway)

also, to be clear, i've moved away from my early pondering of "is every zoom level a 'variation'?", and instead now lean more heavily towards "no, it's not a variation, it's the same page just displayed in a different browser/viewport size", because that's really what it is. this makes an even stronger case for the fact that every SC (minus Reflow) must pass regardless of browser/viewport size (ergo, for every possible zoom level)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants