Reflow Understanding text hard to parse when it talks about 1.4.4

[DavidMacDonald]

I find this sentence hard to parse

... For example, if text is set at 20px when the window is 1280px wide, at 200% zoom it should be at least 20px (so 200% of the default size), but at 400% zoom it could be set to 10px (therefore still 200% of the default 100% view).

What is the 100% default view size, 5px? I've looked at this sentence for 5 minutes and still can't figure out what it is saying.

Also in the example the video doesn't seem to play.
https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

[mbgower]

I also twinged on this yesterday when opening a separate change to existing language for Reflow. I agree it needs some wordsmithing.

[WayneEDick]

Hi, It looks like something from an older version that got carried over. Let's see if it can be fixed or just cut. Wayne

…

On Wed, Mar 13, 2019 at 7:21 AM Mike Gower ***@***.***> wrote: I also twinged on this yesterday when opening a separate change to existing language for Reflow. I agree it needs some wordsmithing. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#658 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF914Akkt9N509eiSm6I6f6Pxcnzjks5vWQligaJpZM4bq5pj> .

[detlevhfischer]

Is this clearer?

For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280px wide, the same 20px at 200% zoom would mean a text size of 200%. At 400% zoom, the author may decide to set the text size to 10px: the text would now still be enlarged to 200% compared to the default browser setting of 100% zoom. It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

I had some misgivings about "in some way", and maybe we can still find a better formulation.

Am I correct in assuming that an author offering reflow but constantly reducing text size when moving to narrower breakpoints (always remaining below 200%) would still meet 1.4.4 if he/she offered a style switcher serving another style meeting the 200% requirement?

[WayneEDick]

Detlev's wording makes this clear, but we should add that the reduction to 200% enlargement over normal satisfies 1.4.4 but not 1.4.10. That is: For example, if text is set at 20px when the window is 1280px wide, at 200% zoom it should be at least 20px (so 200% of the default size), but at 400% zoom it could be set to 10px (therefore still 200% of the default 100% view). This latter adjustment would satisfy 1.4.4, but it would not satisfy 1.4.10.

…

On Tue, Mar 12, 2019 at 6:29 AM David MacDonald ***@***.***> wrote: I find this sentence hard to parse ... For example, if text is set at 20px when the window is 1280px wide, at 200% zoom it should be at least 20px (so 200% of the default size), but at 400% zoom it could be set to 10px (therefore still 200% of the default 100% view). What is the 100% default view size, 5px? I've looked at this sentence for 5 minutes and still can't figure out what it is saying. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#658>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF6E_Ofk3W1IGV60UXgwDUJRkmyW7ks5vV6uqgaJpZM4bq5pj> .

[detlevhfischer]

Hi Wayne,
it is not clear to me why you think 1.4.10 Reflow would not pass when text size is progressively reduced. It is my understanding that Reflow checks single column layout at 320px viewport width, not the text size at that breakpoint. 1.4.4 would instead check whether zoom will reach 200% text magnification at some point OR whether there are alternative means of enlarging text to 200%. Having said that, in most cases 1.4.4 will be met by allowing users to zoom in from default to 200% and not reducing text size at the resulting breakpoint.

[patrickhlauke]

On 18/03/2019 19:43, Detlev Fischer wrote: Hi Wayne, it is not clear to me why you think 1.4.10 Reflow would not pass when text size is progressively reduced. It is my understanding that Reflow checks single column layout at 320px viewport width, not the text size at that breakpoint. 1.4.4 would instead check whether zoom will reach 200% text magnification at some point OR whether there are alternative means of enlarging text to 200%. Having said that, in most cases 1.4.4 will be met by allowing users to zoom in from default to 200% and not reducing text size at the resulting breakpoint.

Agree. 1.4.10 has nothing to do with text size. The note does suggest (non-normatively?) that 320 CSS px is the viewport width you get in a desktop browser as 1280 pixels width when zooming to 400%, but that 400% refers to the zoom factor overall, not the text size. Whether the text size scales in line with zoom, or whether the author has added any extra explicit font sizes for different breakpoints, is irrelevant for 1.4.10.

[patrickhlauke]

Am I correct in assuming that an author offering reflow but constantly reducing text size when moving to narrower breakpoints (always remaining below 200%) would still meet 1.4.4 if he/she offered a style switcher serving another style meeting the 200% requirement?

I would say yes. as having a switcher/configuration options/etc would allow for the text to "be resized without assistive technology up to 200 percent"

[patrickhlauke]

as an aside, an example of a technique passing 1.4.10 but failing 1.4.4 would be a responsive site that sets its font size using purely vh or vw units. A user would be able to zoom to 400% or even further, changing the effective CSS pixel dimensions of the viewport, and - assuming the layout adapts to it - getting to 320 CSS px without causing horizontal scrolling...but having the effective text size never actually change.

(random link to an unrolled thread view of a series of tweets i did about this ages ago https://threadreaderapp.com/thread/927508868686639105.html )

[patrickhlauke]

extrapolating a bit from what i think wayne may be trying to get at, let's imagine a site that does allow zooming up to 400% and reflows correctly, but that (due to font sizing shenanigans) even once you zoom to 400%, you've NOT managed to increase the font size to 200%. to actually reach 200%, you end up having to zoom even further (though most browsers don't let you zoom much further 500%, but let's assume for argument's sake). and say that THEN, once you've managed to get to 200% font size, reflow doesn't occur and scrollbars do happen. i'd say there that the site PASSES 1.4.10 (as zooming until the viewport is only 320 CSS px width was indeed possible), AND it PASSES 1.4.4 (as it was possible to increase text size to 200%).

If, at that much higher zoom ratio (and much smaller viewport size in CSS px), once 200% text size was finally reached, the layout starts to break apart though (things overlapping / getting cut off, etc), then it still PASSES 1.4.10, but then FAILS 1.4.4 (as there's a loss of content/functionality).

[WayneEDick]

The entire reason the LVTF created Reflow was to get reasonable enlargement. At 200% half of the target audience needs another form of enlargement to read. That requires 2-d scrolling to obtain functionality. I assume that the function of text is to be read. For people like me 200% is not sufficient for reading. That is 40% of LV according to the WebAim survey, or about 1.2 million in the US. We did not mean that reflow could be achieved by making font smaller. The old 1.4.4 simply left out a huge population. Best, Wayne Also, suppose a person with tunnel vision shrinks width to 320 CSS pixels. That should not trigger a font size drop to 50%.

…

On Mon, Mar 18, 2019 at 2:09 PM Patrick H. Lauke ***@***.***> wrote: extrapolating a bit from what i think wayne may be trying to get at, let's imagine a site that does allow zooming up to 400% and reflows correctly, but that (due to font sizing shenanigans) even once you zoom to 400%, you've NOT managed to increase the font size to 200%. to actually reach 200%, you end up having to zoom even further (though most browsers don't let you zoom much further 500%, but let's assume for argument's sake). and say that THEN, once you've managed to get to 200% font size, reflow doesn't occur and scrollbars do happen. i'd say there that the site PASSES 1.4.10 (as zooming until the viewport is only 320 CSS px width was indeed possible), AND it PASSES 1.4.4 (as it was possible to increase text size to 200%). If, at that much higher zoom ratio, once 200% text size was finally reached, the layout starts to break apart though (things overlapping / getting cut off, etc), then it still PASSES 1.4.10, but then FAILS 1.4.4 (as there's a loss of content/functionality). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#658 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF-RdnNOpn0fK_fAW9Wt4so5pL1EZks5vYAB_gaJpZM4bq5pj> .

[patrickhlauke]

Wayne I understand where you're coming from, but: that's not now in the normative text. Coupling these SCs together in this way would be a substantive change, which can't be done just through adding some bits to the understanding docs.

[alastc]

Detlev’s update looks fine to me, if people find that clearer.

@WayneEDick we’ve been around this a couple of times - if we require text to get to 400% larger, that would also capture times when it is unhelpful to do so. The only (relatively) common instance of shrinking text in a major way is for headings that are very large to start with. Making a heading 4 screens high doesn’t really help anyone.

In general (as we discussed) people don’t reduce the body-text size at higher zoom / smaller screens because it would be unreadable to most people.

@patrickhlauke - we have a failure for using viewport units to restrict text size.

[WayneEDick]

Hi Alastair, I wrote about this in 2006, E. Dick, Wayne. (2006). Using cascading style sheets to accommodate websites for individuals with low vision. ACM SIGACCESS Accessibility and Computing. 13-19. 10.1145/1127564.1127566. I know the heading problem. I think the way it is presented confuses it with 1.4.4. The stated goal at the is to enlarge text effectively. The first paragraph makes this clear. Also, there is a more serious problem. We did not have signficant input from people with low vision. The data format used by the committee made this too difficult. I missed this. John Rochford couldn't follow gitHub. To doctors who got their degrees with low vision, could not participate. We maybe need to go around this with John and me included. This is solvable. Best Wayne

…

On Mon, Mar 18, 2019 at 3:34 PM Alastair Campbell ***@***.***> wrote: Detlev’s update looks fine to me, if people find that clearer. @WayneEDick <https://github.com/WayneEDick> we’ve been around this a couple of times - if we require text to get to 400% larger, that would also capture times when it is unhelpful to do so. The only (relatively) common instance of shrinking text in a major way is for headings that are very large to start with. Making a heading 4 screens high doesn’t really help anyone. In general (as we discussed) people don’t reduce the body-text size at higher zoom / smaller screens because it would be unreadable to most people. @patrickhlauke <https://github.com/patrickhlauke> - we have a failure for using viewport units to restrict text size. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#658 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF46MS9iqYcq8iARzwblZBnirYEqDks5vYBR4gaJpZM4bq5pj> .

[detlevhfischer]

Proposed working group response:
We suggest to change the text as follows (compare #702)

For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280px wide, the same 20px at 200% zoom would mean a text size of 200%. At 400% zoom, the author may decide to set the text size to 10px: the text would now still be enlarged to 200% compared to the default browser setting of 100% zoom. It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

[alastc]

The PR got merged, and I think there's another PR on the same topic and section of the document which will go into the survey this week.

[MikeElledge]

Hi Everyone, Can we return to David’s question for a moment? Shouldn’t we mention that the default text is 10 px? Assuming that is correct...otherwise it doesn’t make sense (at least to me). Note: I didn’t see Detlev’s response, so maybe it was addressed. “For example, if text is set at 20px FROM A DEFAULT OF 10px when the window is 1280px wide, at

200% zoom it should be at least 20px (so 200% of the default size), but at 400% zoom it could be set to 10px (therefore still 200% of the default 100% view).

Mike

…

On May 10, 2019, at 7:04 AM, Alastair Campbell ***@***.***> wrote: The PR got merged, and I think there's another PR on the same topic and section of the document which will go into the survey this week. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mraccess77]

It might be helpful to mention zooming sets a scale factoe otherwise ira confusing.

[patrickhlauke]

yeah...the tl;dr is really:

• 20px at 100%
• user bumps zoom to 200%, it now is still 20px, but scaled x2, so APPEARS 200% in size (appears visually as 40px)
• if the author now has some media query or whatever that at kicks in when zooming to 400% (because it changes the viewport width and triggers some "smaller screen" styles) and sets the base size to 10px, the end result is 10 CSS px scaled x4, so still appears as 40px size

[alastc]

Ok so how about this?

For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280px wide, the same 20px at 200% zoom would show an apparent text size of 40px. At 400% zoom, the author may decide to set the text size to 10px and the text would still be enlarged to an apparent 40px. It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

Also noting there is another PR (#715) for the paragraph above, and another issue (#704) about the concept of starting points for reflow.

[patrickhlauke]

Ok so how about this?

Yup, I think that now makes it even clearer.

[DavidMacDonald]

I agree with Patrick, but the last sentence of @alastc proposal has me scratching my head.

It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way.

Don't we have to be able to get 200% (of the base value) at any breakpoint. Am I missing something? If so, I assume others less familiar with the subject will be more confused. How about something like this ...

It should be possible to get 200% text enlargement of the default text size at each break point. The author may reduce the font size at narrower breakpoints if doing so still allows a 200% zoom over the default text size at 1280px, although it is recommended not to reduce the font size at narrow breakpoints.

[patrickhlauke]

Depending on breakpoints, you may already end up jumping to an adjacent breakpoint before you zoomed the content to 200%...so it's impossible to say that at each breakpoint users must be able to get to the 200% text size. But what it means is that from their starting zoom, they must be able to eventually reach a state/breakpoint where the text is indeed 200% the original size (regardless of whether they're still in the same breakpoint, or if their zooming resulted in triggering another breakpoint)

e.g. a site may have breakpoints at "anything greater than 1280 width", "1024 - 1280 width", "800 - 1024 width", "400 - 800 width", "anything below 400" (or some similar granular arrangement). For most starting widths, you can't zoom to 200% without sliding into another breakpoint, so you'd never be able to say that for each breakpoint (and without triggering another breakpoint) users must be able to get 200% text size. now, whether developers change the actual base font size or not for each breakpoint is another matter...it's not a given, and beyond some minor tweaks, it's rarely done. If we feel it's common, we can probably address this, but with a separate note (rather than overloading this text further)?