Please clarify the actual goal of SC 1.4.4 in the understanding documents

It has always been my understanding that the primary subject of SC 1.4.4 is resizing of text, that the inability to resize text to 200% is a failure, that visual defects as a side effect are a failure, and that controversy is mostly limited to what constitutes an acceptable mechanism. In particular page zoom versus text zoom, I am aware of all those discussions in this tracker.

Long story short, our leading WCAG experts at work recently responded to a query of mine about our internal testing method and announced that if the text is somewhat bigger at 200% page zoom and the layout does not break, the criterion is satisfied.

Incidentally, I recently noticed this in the WCAG primer of the UK Government Digital Service:

all text is bigger (it does not need to be exactly 200%)

https://github.com/alphagov/wcag-primer/wiki/1.4.4#check-zooming-in-and-resizing-text

My personal impression is, that the prose in many understanding documents is so verbose, that the normative text of the SC is drowned. But maybe I'm wrong.

[TestPartners]

I would not give any credence to that UK Government Digital Service test process. It's written by people with less experience than most of us here, and I have found other recommendations in there that I don't agree with. Their test process isn't terrible, but it's certainly not authoritative.

I would also say that your "leading WCAG experts at work" are quite clearly wrong. The normative text is clear and simple and requires that text can be resized up to 200%. There is no mention of zooming and no mention of "somewhat bigger".

[TestPartners]

The test process is quite challenging because the base text size can change at different viewport widths. Last week I tested a website where the base text size was different at EVERY viewport width (and hence every zoom level) because it was specified as a formula rather than a number!

You therefore need to check the computed font size at 100% using the DOM Inspector, then increase the zoom level until the product of the computed base font size and the zoom level is at least twice the initial size. If the base text size does not change, which is the case with most websites, this will happen at 200% zoom. But on some websites you need to increase the zoom level further.

Worse still, in principle you need to do this separately for every piece of text because they may not all change size at the same rate. I am working on an idea for a bookmarklet that can do most or all of these calculations so the tester just needs to change the zoom level.

I would not give any credence to that UK Government Digital Service test process.

I don't, it's just supporting public anecdata that there are multiple parties who have reached a diverging opinion about what does and does not satisfy the SC. I'm somewhat concerned about reach and impact by association though. But my prime concern is my work. While the internal process isn't public, the impact is in output volume.

There is no mention of zooming and no mention of "somewhat bigger".

Page zoom is mentioned in the understanding docs. I have no issue whatsoever with the normative text. Acceptance of page zoom as a mechanism that satisfies the SC seems to have convinced certain parties that the testing process is:

1. Zoom the page to 200%
2. Check that everything is still pretty

You therefore need to check the computed font size at 100% using the DOM Inspector

I really do not wish to discuss testing methods in this issue, but computed size does not necessarily reflect rendered size, examples being CSS zoom or transforms anywhere up the tree.

[TestPartners]

Sorry, I misunderstood - I thought the whole purpose of this thread was to discuss testing methods. That said, you're right about CSS zoom and transforms. It seems there is no way to programmatically get the rendered size - all you can do is get the base size, CSS zoom value and transform value and hope that nothing else is affecting the size.

[mbgower]

Official Working Group Response
In order to meet 1.4.4, text must be able to resize up to 200 percent without loss of content or functionality.

You mentioned a scenario where:

The test process is quite challenging because the base text size can change at different viewport widths. Last week I tested a website where the base text size was different at EVERY viewport width...

Then you mentioned advice from a WCAG expert that if the text is somewhat bigger at 200% page zoom and the layout does not break, the criterion is satisfied.

Some of the confusion may have resulted from information concerning 1.4.10 Reflow, a related but separate criterion which is ultimately concerned with ensuring that text can reflow within the viewport as it increases in size. The Understanding document contains the following text:

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.

In short, a user must be able to reach 200% of the default text on the page. Typically, this is achieved on a 'desktop' monitor without reaching a breakpoint. However, there is not a requirement that 200% can be achieved within each breakpoint; some designs, especially at narrower widths, may reach a new breakpoint and achieve 200% of the starting text size there.

[bruce-usab]

Discussed on TF call 12/6, no concerns with proposed response.

Draft Working Group Response In order to meet 1.4.4, text must be able to resize up to 200 percent without loss of content or functionality. [...]

Thanks for the WG reponse. I would like to apologize for the poorly formulated issue, including the primary request. My mind is quite clouded at the moment. Luckily, the answer did provide some hooks for a complete reformulation that will hopefully be more clear. Sorry if that is a wall of text.

In my understanding, these are the two facts concerning SC 1.4.4 that are relevant for this issue:

• The SC requires the possibility of 200% text size
• The understanding document establishes page zoom as a mechanism

And this appears to be the most common testing methodology in Germany:

• Increase page zoom from 100% to 200%
• Check the result for visual defects

The good thing is, beyond the proprietary testing methodology I mentioned, there is also a public testing methodology for the Europan WAD that can be referenced here. Together, to the best of my knowledge, that represents the foundation for the bulk of WAD tests in Germany at present.

https://bitvtest.de/pruefschritt/wcag-22-web/wcag-22-web-1-4-4-text-auf-200-vergroesserbar

The testing steps are described in the disclosure widget “Wie wird geprüft?” under section 2.1. The instructions clearly require 200% page zoom (even explicitly referring to layout size for Firefox, and somewhat absurdly even mentioning the number of times the keyboard shortcuts have to be used, as if those increments of the platform UI can never change) and verification that no visual or functional defects have been introduced. No mention of text-size here. Done and dusted.

My problem with this procedure is, that the assumption that the page zoom percentage equals the resulting text size percentage can be correct, and often is, but it does not have to be. I regularly test sites where 200% page zoom results in text that is roughly 160-180% of its initial size. Most often because of breakpoints, calculations with viewport units, or a combination of that.

To reiterate, I’m being told that those cases satisfy SC 1.4.4 and I’m done testing the SC at this point if no visual effects exist.

It seems very straightforward to me, that in those cases the tester should attempt to further increase the page zoom until either the text size is increased to 200% and then check for visual defects, or the maximum zoom level is reached.

Page zoom is not text zoom, the fact that the Zoom scale factor is represented as a percentage in the GUI might be confusing but is irelevant for meeting the SC, and IMNSHO SC 1.4.4 should indeed not be tested as a 50% version of 1.4.10.

So if I’m right, I appear to be a regional minority among seasoned experts. To summarize with an example, here’s a slightly modified scenario from the one you quote from 1.4.10:

• At 100% page zoom the text size is 20px
• At 200% page zoom, the CSS font-size property is set to 10px, resulting in 20px/100% text size
• At 400%, the text size is 40px/200%
• SC 1.4.4 is satisfied

Would you (the WG) agree? If so, my request would be to somehow better reflect that in the understanding documents for folks who do not agree, because I think there is a very real necessity.

[JAWS-test]

@besenwagen
I do not believe that the test procedure you mentioned does not check whether the text can actually be enlarged to 200%. On the contrary, the page explicitly states:

Text should be able to be enlarged by up to 200 per cent without losing content or functionality. ... Using the browser's zoom function, the font can be enlarged to 200 per cent ... Rating: Fulfilled: The text can be enlarged to 200%

I think the misunderstanding only arose from the fact that there were no media queries and breakpoints when WCAG 2.0 SC 1.4.4 was formulated, so that 200% browser zoom always led to 200% text enlargement. This is now different and therefore the WCAG understanding and the German test procedure should be adapted.

@JAWS-test I‘m not saying that the page misrepresents the spirit of the SC (does anybody remember the spirit of SGML in NOT the comp.text.sgml FAQ?), my concern is that the rather meticulous testing instructions that I referred to do not represent it.

I didn’t want to make that message even longer, at the time WCAG 2.0 was released, even proper text zoom was relatively new in the mainstream (Internet Explorer 7) and page zoom had just landed in the margins (Firefox 3; the only people I knew who even knew about Opera, let alone use it, were all geeks). But even without that history, personally I see nothing wrong here, neither with the SC nor the understanding docs.

That’s why I’m so surprised that this has become a difficult topic for me after I moved to Germany. Be that as it may, I’m uncertain now and seek reinsurance. Hence this issue.

[alastc]

I agree with your scenario here:

• At 100% page zoom the text size is 20px
• At 200% page zoom, the CSS font-size property is set to 10px, resulting in 20px/100% text size
• At 400%, the text size is 40px/200%
• SC 1.4.4 is satisfied

And to add the fail case:

• At 100% page zoom the text size is 20px
• At 200% page zoom, the CSS font-size property is set to 10px, resulting in 20px/100% text size
• At 400%, the CSS font-size property is set to 8px, resulting in 32px/160% text size
• Further zooming does not increase the text size to 200%
• SC 1.4.4 is NOT satisfied

(Caveat: These zoom levels are assuming a large starting point, as the media queries are usually based on CSS pixel width. It might be better to state as starting at over 1000px wide and zooming to 500px etc. It's tricky, because that gets very technology-specific very quickly.)

See also F94

We do already have this note, which appears to address this issue (bold added):

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.

And the bit at the very top says:

What to do: Ensure text can be doubled in size.

What other text would you want added?

Hi, and apologies for the delay.

I agree with your scenario here:

That is nice to read.

See also F94

I am aware of it, and it is great that an example with technology that has emerged after the spec was released has been added. My only gripe with it is, that this is a very binary and somewhat academic use case. The inability to resize text at all, other than resizing the user agent window, is unlikely to cause controversy.

Viewport units, at least in sites that I encounter, are often used in combination with the calc function, with or without an entire implementation of typographic scale. I guess what I would appreciate to see is a failure technique where text can be clearly enlarged, but not sufficiently. Because breakpoints, or viewport units, or both. Again, not for my own understanding of the SC, but to settle diverging interpretations.

We do already have this note, which appears to address this issue (bold added):

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.

On rereading, I agree that this sufficiently addresses the issue in prose. And appreciate the answers. At least my own view has been reassured.

I wouldn‘t mind drafting a failure technique suggestion, but I have no knowledge of procedure there, so I don‘t know if that would be useful, or even welcome.

[mbgower]

@besenwagen

I wouldn‘t mind drafting a failure technique suggestion, but I have no knowledge of procedure there, so I don‘t know if that would be useful, or even welcome.

You could compose it as text document, or you can review the process for Creating a PR.

Since we have received support for the draft response through a working group review, I am relabelling it as the official response and closing this issue as