there will often be very different content on different screens (to avoid using "view" here), and it is useful in practical terms to record issues per screen

Sure, but sampling and reporting are not constrained by the conformance-unit.

VPATs for example make no requirement on sampling, or even reporting by page. The scope is self-selected. (It sort of implies it's the whole product/site, but in most cases it must be a sample, right?)

We navigate to the different screens of the mobile app and insert them as so many screens of our testing sample, focusing on differences in content - so if a screen is structurally the same as another one that is already in the sample, we would not include it. Depending on the app, that could be 5 or 10 or 15 or 20 or even more screens. So it is not really different from picking a sample for web sites.

A very reasonable approach, but it can be hard to define the boundaries. For example, modals, pop-overs, slide-in things, full screen videos. If there were a way of defining each (intuitive) screen as an anchor point from which all components could be included, that would be great, but I don't see a way to define that.

You want to make sure that all relevant diverging content of an app is covered. But thinner-slicing ensures that the report per SC does not get too unwieldy. Otherwise you'd need to subdivide your evaluation results per SC into different sections for the different screens. (You also want granular issues if you provide issue export to JIRA etc.)

It goes both ways, if thin-slicing the slack-app (example) then it has a multitude of potential screens that are all different content, but functionally identical. Reporting by screen would be very repetetive, as the same issue would apply across many screens.

I guess it is a case of whether it is better to:

• Have a wide scope of "view", and in practice we sample within view.
• Have a narrow scope of "view", and in practice we sample across views.

Either way, I assume that we would be sampling for different content types and functionality. The conformance unit isn't particularly useful for that either way.

You would create a slice only where you see difference in structure or content. If screens are structurally and content-wise equivalent to one we already have covered, we would not include them in the sample.

But how do we define "difference in structure of content"? (And again, sampling is different from conformance unit, see the "Sampling" thread above.)

The point [of amount of change] is qualitative. You just want to ensure you include all different components there are.

But we need it to be (at least somewhat) objective. And talking about different components is about sampling, not the conformance unit.

I do not see how that introduces fickleness or odd results.

If the definition is based on an amount of change (e.g. 50% of content, or 50% of controls on the page), then you could have two very similar screens, but one is it's own view and one is not. What about a screen which has an accordion, compared to another screen which doesn't?

If there is an issue identified, the difference might be that you find it reported on several screens if you include more that share this issue, or just once if you were more parsimonious. But diligent sampling should ensure that the issue is covered within the sample (and there is no absolute guarantee that nothing will be missed, as always).

Again, how something is reported and how it is sampled is separate from the conformance-unit. You can report by page/view, but you don't have to.

A WCAG conformance statement would ask which pages/views were included, so in that case you'd need to note which were included in your sample, but I don't see that process changing with the view definition. Sampling is all based on smaller units anyway.