@mbgower

Where the size of the viewport or the size of the content can be altered..."

1. For mobile apps, would you interpret this as being true whenever the orientation of the device (and thereby the viewport width) can be changed?
2. For mobile apps, even where orientation is locked, the platform may (or may not) afford split screen views and thus different viewport dimensions for content. Would this mean that the viewport sitze can be altered in principle even if the actual possibility may depend on the device and its OS where the app is running?

Interesting questions, @detlevhfischer.
For question 1, turning a device sideways does not alter the size of the viewport, right? You've merely altered the orientation. We have a success criterion that covers that. However, as you point out, unless the viewport is a square, when you change orientation, in the situation where you go from a wider to a thinner width, one of two things needs to happen in order to support orientation: either you require horizontal scrolling to maintain a static layout of content, or you need to resize. It is entirely possible to support re-orientation without changing aspect ratio of content or requiring horizontal scrolling. Just think of an image that simply gets bigger or smaller to fit the width, while maintaining the relative height. Likewise, all content could respond in lock step and not need to reflow. That seems to meet this wording, but I can see how someone could argue that content becoming tiny is not the desired outcome. So maybe we have to think through the wording and context more.
To answer question two, I think we need more information than you've supplied. For instance, I've seen split views where each side maintains its prior dimensions by using horizontal scrolling. I've also seen ones where the user has the option of allowing text wrapping. I guess the exception language can cover that?

Thanks for highlighting some problems with the first draft of the wording --and maybe with the overall approach!

For question 1, turning a device sideways does not alter the size of the viewport, right?

I guess it may, or may not. With some apps, it appears to be the case that content adapts to a wider viewport and reflows - take the default iOS Mail app, for example. In other apps, content appears simply enlarged but breaks at the same place.

I guess it may, or may not. With some apps, it appears to be the case that content adapts to a wider viewport

Sorry, what I meant is that the size of the window/screen -- does not change by changing the viewport. It is still width x height. it's just that those numbers are inverted. So the overall size of the viewport (the dimensions you can see) is not changed. What is shown in the viewport may change, but that's a very different thing than resizing the window by grabbing the resize button and making it half it's current width (which is what Reflow is about)

@mbgower ah - sure, so read "viewport width" instead of "viewport" (assuming that width will always be the horizontal dimension) - which is what determines breakpoints (in Western languages) and in turn reflow behavior.

Confirmed that this issue is included in the Reflow scratchpad

@detlevhfischer if you're interested in being part of that discussion, or joining the WCAG 2.x TF that's dealing with these kinds of things (and meets Fridays at 3PM GMT

@mbgower At the moment I just can't find the time...

First impressions, I feel like:

Where the size of the viewport or the size of the content can be altered...

Is too big a loophole for web content. I am open to being convinced otherwise.

It does seem perfectly reasonable to me for non-web documents and non-web software (and especially platform-specific software).

I think you have to look at various use cases for viewing web content:

• Where web content is designed for use on a phone (e.g. a certain presentation for phones using responsive design) - Some phones may not support the viewport CSS pixel width or height as specified by WCAG in CSS pixels. Should one test to the nearest supported height or width as the case might be? The SC and guidance don't cover that situation. Is its scrollable viewport allowed to be larger than the specified CSS pixels? Is it allowed to be smaller?
• What happens when a user agent doesn't support that particular width or height for scrolling? E.g. when a user agent on a tablet provides multiple web pages to be viewed at a time side-by-side. The scrollable viewport may not be able to be viewed at the scrolling width or height specified by WCAG. Should there be a tolerance, or a more generic application of the SC, or not be a hard requirement at that point?
• What about a web TV? Is a user able to adjust the viewport?
• Consider a desktop-based web browser. I don't think they always support resizing the window to the scrolling width or height specified.

Perhaps some notes could be written to the effect that where a user agent doesn't support the scrolling width or height specified, that the web content will reflow to scroll within the size the user agent supports.

First impressions, I feel like:

Where the size of the viewport or the size of the content can be altered...

Is too big a loophole for web content. I am open to being convinced otherwise.

It does seem perfectly reasonable to me for non-web documents and non-web software (and especially platform-specific software).

I must admit I do not see the loophole.
Web content runs in a browser, and the browser window sine can always be chnaged, and the browser provides functionality to change text size.