Problematic definition of view

[WilcoFiers]

I've raised concerns about using an early version of WCAG 3.0's views definition before. Since we're in a review period, I'll bring it up again. The proposed definition of views is borrowed from the draft of WCAG 3.0:

The content that is actively available in a viewport, including that which can be scrolled or panned to, and any additional content that is included by expansion, while leaving the rest of the content in the viewport actively available.

I think that's an okay definition for "developing" but I think that definition is far from done. But for us to use that in WCAG-EM we need to have the kinks ironed out first.

1. "content": This is not defined. Presumably this just means everything that is even remotely associated with the viewport. I would argue that audio isn't "in" the viewport, and neither is the accessibility tree. The intent is sort of here, but it seems like the wrong choice of words.

2. "available in a viewport": This is more problematic. Viewports can be nested. Iframes are literally nested viewports. Can a "view" be just the content of an iframe, and the inverse, can an full web page exclude the content of an iframe because it isn't part of its own viewport? I think there's an argument to be made here that if an iframe loads content that isn't part of the digital product that it shouldn't be considered part of the view. That's not how WCAG 2's conformance model works. In either case I think these kinds of details need to be spelled out explicitly.

3. "scrolled or panned": Infinite scrolling and panning didn't really exist when the web page definition was written, but it is now. WCAG-EM builds on the idea that you can do a full audit of a simple. On an infinitely scrolling / padding screen that isn't the case. I don't think this is something should leave for testers to decide on individually. There are also things that load infinitely such as calendars.

4. "content that is included by expansion, while leaving the rest of the content in the viewport actively available": This is the biggest problem I have with the definition. If I expand a tooltip that then sits on top of some other content, that seems to suggest some content is no longer "actively available" and so it becomes a different view. Expanding a mega menu often overlaps a heading, that would seem to now be a different view. Checking that my billing address is the same as my delivery address hides a section of the form, that would seem to be a separate view. I can go on for a very long time here.

5. If I adjust the viewport size or rotate my screen, elements change, some content may be truncated or hidden behind a button, it would seem these are part of different views too. That seems especially problematic, since it almost makes it so that certain views simply don't exist in certain viewport sizes, making the resize and reflow criteria an auto-pass. I think viewport sizes and screen orientation need to be explicitly addressed in WCAG-EM now. Finding these breakpoints should be part of step 2, and which viewports were tested needs to be documented in the audit, just like which browsers / AT were used.

I can live with point 1, but the rest in my opinion needs to be tackled in a v2. I appreciate the group is trying to keep it's scope small, but the web isn't what it was when this document was first created. I think updating this to make it work for a modern web should be a higher priority than even making this work for non-web applications.

[hidde]

+1 that making this work for a modern web, in all the ways it has evolved since WCAG-EM 1, is as much a priority as making it work for non-web. We definitely want both, it's why we updated the definition to what it is now.

Re: content: do you expect there to be misunderstanding or interpretations that could lead to the EM to be applied in ways we don't intend? I can't think of any but it would be good to know. My feeling is 'content' is fine, we need a word that is generic enough.

Re "available in a viewport": would be happy to explicitly exclude iframes, eventhough that would introduce a web-specific exception. I think for all other types of nested views, like nested React components, there is no need for exclusion. What about adding a note that says 'Note: in the context of web pages, an <iframe> is considered a new view and not part of the view it is contained in.' or something along those lines?

Re "scrolled or panned": if a web page infinitely scrolls or has an infitely expanding calender, I would say that's totally part of the same view, and not problematic in terms of evaluation, as it is very unlikely that infinitely added content differs that new issues would arise (eg would you say in the 400th row of new products added in a search result, it is likely an evaluator would find a new accessibility issue in the 400th row that wasn't in previous ones?).

Re: "content that is included by expansion (…)": interesting observations, I'd absolutely consider content behind a tooltip to be actively available. The example we give with the definition of view is of content behind a modal overlay, in other words, inert content. Billing address sections and content behind megamenus both definitely don't constitute new views, they are examples of 'included by expansion'. That this wasn't clear to you suggests to me it's not clear for many: let's update the definition to make that clearer, suggestions welcomed.

If I adjust the viewport size or rotate my screen, elements change, some content may be truncated or hidden behind a button, it would seem these are part of different views too.

No, these are all meant to be the same view. We had that clearer in previous iterations of the definitions and it'd be great to readd that in an update of the definition.

Summing up:

• re def of content, scrolling, panning: I see what you mean, but don't think these warrant updates.
• let's add a note to explicitly exclude nested iframes from being part of the views they are nested in
• let's update the definition to make it clearer that views aren't changing with viewport size and orientation, megamenus, expanding sections and others.