-
Notifications
You must be signed in to change notification settings - Fork 285
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
Comments
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. |
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) |
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. |
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. |
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) |
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:
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. |
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. |
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. |
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%". |
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) |
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:
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).
The text was updated successfully, but these errors were encountered: