Expand 1.4.10 Reflow note about 200% and breakpoints, add matching note to 1.4.4 Resize Text #2630
Conversation
also correct minor typo in preceding sentence.
|
Putting this down as an initial strawman change. Happy for any improvements/suggestions to possibly take this further. |
|
Can we change the 2nd 200% in first example sentence to use px?
(I am holding my breath to see if that [second] 200% becomes 40px or 28.3px.) |
|
not sure i follow where you got the 28.3px from. that whole sentence, which I left mostly untouched, is a bit dense and confusing though. will see if i can make it clearer what's actually going on there. |
|
Done. reworded to possibly make a bit more explicit what the 20px at 100% / 10px at 400% was getting at. |
|
I am unsure if this is the intention of the SC. I think the reason for 1.4.10 is,
Low vision users may need a high zoom factor to read content. Therefore the first reason (400% zoom) is much more important than the second (no scrolling). Unfortunately, 1.4.10 is worded to focus only on the second reason, but the Understanding explains that the intent is actually primarily the first reason. If we don't require 400% zoom now, we give up the point of 1.4.10. Then SC 1.4.4 and combination with SC 1.4.8 ("Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text", at level AA instead of AAA) would be sufficient. I am aware that Understanding already says that 200% magnification at 400% zoom is sufficient. In response to my previous inquiries about the meaning of this sentence, I was told here in the forum that this exception only applies to large text (such as headings), which would become much too large at 400%. |
That would be I think at one point there was discussion if 200% meant twice the ~number of pixels or twice the font size. (Since a square 40px on at side has 4x the area as a 20px sided square.) I was not entirely clear where AGWG landed on that detail.
Should this not be?
Examples based on 16 css px would be a little more typical. |
First I heard of it in the context of "text size" (which usually refers to the height/x-height/etc of a font). It may have come about from other discussions about target size and/or size of enhanced focus area (where we do want to talk about area)
It's a truism, but one that was there to begin with. And it then sets up the contrast to the next sentence where that isn't the case due to the new media query.
This whole thing would then veer into disambiguating between CSS pixels and display pixels, and at which display density that would be true. maybe something like "would mean text is displayed at an effective size of 40px (because it's not the actual measure that changes, but the way it's displayed/the CSS pixels are converted to display pixels)
but make slightly uglier numbers... |
|
also, you seem to be commenting on the original text still, rather than my curent PR text? my PR changes that bit about "at 200% zoom it will be 200%" to a slightly less silly sounding
|
That must have been the case, my apologies.
This version is not silly sounding at all IMHO. Still, my preference would be to say 40px rather than twice the size. It is good enough though, and better than what we had before. |
|
The second is (almost) as important as the first
(Both are nearly equally important)
When you require horizontal scrolling - it makes it very difficult to read anything - including finding the beginning of the next line. Tracking back to find the next line is very hard when you need to horizontally scroll and cannot refer to the end of one line while also seeing the candidates for next line.
Gregg Vanderheiden
***@***.***
… On Aug 23, 2022, at 12:00 AM, JAWS-test ***@***.***> wrote:
I am unsure if this is the intention of the SC. I think the reason for 1.4.10 is,
to allow 400% zoom,
to simplify reading at 400% zoom by not requiring scrolling.
Low vision users may need a high zoom factor to read content.
Therefore the first reason (400% zoom) is much more important than the second (no scrolling). Unfortunately, 1.4.10 is worded to focus only on the second reason, but the Understanding explains that the intent is actually primarily the first reason.
If we don't require 400% zoom now, we give up the point of 1.4.10. Then SC 1.4.4 and combination with SC 1.4.8 ("Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text", at level AA instead of AAA) would be sufficient.
I am aware that Understanding already says that 200% magnification at 400% zoom is sufficient. In response to my previous inquiries about the meaning of this sentence, I was told here in the forum that this exception only applies to large text (such as headings), which would become much too large at 400%.
—
Reply to this email directly, view it on GitHub <#2630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQSJBOXUY5RTYPDY2TV2RZJZANCNFSM57I4MDHQ>.
You are receiving this because you are subscribed to this thread.
|
|
If I need 400% zoom, then
The difference between NOT PERCEIVING and DIFFICULTLY PERCEIVING seems important to me. |
|
See #658 (comment) and #1050 (comment) The exception that content does not need to be zoomed four times at 400% zoom was intended for large text like headlings. Unfortunately, this information never made it into Understanding, although it is completely incomprehensible to me why not, because it's the crucial information for 1.4.10 - otherwise 1.4.10 is worthless in terms of 400% zoom. |
|
@JAWS-test The 1.4.10 Reflow SC has nothing on differentiating between body text and headings and nothing on requiring 400% body text. (That line would be difficult to draw anyway.) Yes, there is a user need for zooming text to 400%, but it is not a normative requirement (yet). I think it is important to distinguish between "what this SC ideally means" and what is put down in the normative text. |
|
@detlevhfischer Yes, I am aware of that. But I think this is a mistake, because then according to 1.4.4 I can support 200% zoom and at 400% zoom I can theoretically even shrink the font four times to comply with 1.4.10 Reflow. However, this contradicts the intention formulated in the first sentence of the understanding:
|
|
I think we should include some illustrations, especially in the resize text Understanding document. |
|
@JAWS-test regarding you're comments, I just wanted to ensure you were aware of what is currently stated under "The relation of Reflow to the Success Criterion 1.4.4 Resize Text" in the existing Reflow Understanding. |
|
Briefly mentioned on TF call 4/12. This PR should be part of Reflow discussion. Even briefer mention on call 4/29. |
|
@bruce-usab when zooming, the CSS px measures don't change (it's only the browser's internal mapping of "how many actual display pixels do i use to represent a single CSS pixel" changes). so i really don't think it'd be helpful to start talking about also, refreshing my mind about your "28.3 pixels" thing early on, note that when zooming to 200%, you're not zooming with some square root calculation ... you're doubling the horizontal and vertical dimensions, i don't believe any implementation of zooming considers the actual area of things, but just changes the horizontal and vertical dimensions of how a CSS pixel is represented by that particular factor. |
|
@Leeze555 can you just ... shush and go away? |
|
Will see if I can add an illustration/diagram somehow (and clarify how the "at 400% zoom" relates back to the original size, not "320 CSS px and THEN 400%") |
Co-authored-by: Scott O'Hara <scottaohara@users.noreply.github.com>
|
@scottaohara tweaked and applied your suggestion, and then made the same change to the other file as well to match it. |
|
Mulling this note, which is a good clarification in substance, I still have some questions as to where it belongs and what it means for UA without windows and UA-based zoom function. The note states:
I wonder about the "automatically presented" - because it sounds tailored to user agents that have no windows (where the size and/or zoom factor may be changed any time) but use the entire screen as viewport (i.e., phones, tablets). And here we are in a situation where reflow may not work (or not be testable) when the UA does not offer a zoom function triggering reflow the same way as in desktop browsers. So the note does not really clarify if and how this SC would then apply in such windowless environments. Should content reflow when the viewport changes due to other applications loaded alongside the browser split screen mode, or when device orientation changes change the viewport width? Maybe this is another issue that must be addressed elsewhere. The second thing is that the note talks most about the effect of reflow on text size and what that means related to 1.4.4. That's fine - but is this then not a note that would really belong to 1.4.4, with a note here (in 1.4.10) merely stating that the reflow requirement (as stated normatively) is independent from the text resizing requirement, and refer to the discussion of text size under different viewpoint width /media quer conditions in 1.4.4? |
Closes #1839
Related: #2101 #704