Please clarify the actual goal of SC 1.4.4 in the understanding documents #4157
Comments
|
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". |
|
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 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.
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:
|
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. |
|
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. |
|
Draft Working Group Response You mentioned a scenario where:
Then you mentioned advice from a WCAG expert that 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:
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. |
|
Discussed on TF call 12/6, no concerns with proposed response. |
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 And this appears to be the most common testing methodology in Germany: • Increase page zoom from 100% to 200% 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 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. |
|
@besenwagen
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. |
|
I agree with your scenario here:
And to add the fail case:
(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):
And the bit at the very top says:
What other text would you want added? |
|
Hi, and apologies for the delay.
That is nice to read.
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.
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. |
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:
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.
The text was updated successfully, but these errors were encountered: