Discussion on defining "view"

[scottaohara]

Thanks to @hidde-logius for the presentation today.

Opening this discussion thread for anyone to provide ideas on where they'd like views to go / any thoughts on the current presentation/documentation that's been provided.

[mbeganyi-a11y]

+1 to thanking @hidde-logius for the presentation and work. Not an easy undertaking! Very well done.

I appreciate the word "view" and think this helps to capture other interfaces that can be included in such a change of terminology. I don't think that saying to authors after WCAG 3 comes out: "Yeah we changed the definition of page and now that means mobile" will be particularly helpful.

Will think more on it, but this is my immediate response.

[hidde-logius]

Thanks Mike.

To clarify, do I understand your comment correctly as saying you’d prefer introducing a new ‘view’ definition to talk about a wider range of interfaces to changing the ‘page’ definition to do that?

[mbeganyi-a11y]

Hi Hidde. Yes, I'd prefer to see a new term introduced. Of course it could include aspects of the current definition of "page" but I believe "view" would incorporate a wider range of technologies in present and future.

[stevefaulkner]

Can we decide whether we need a subview categorisation? What function does it serve? I have heard @scottaohara mention (paraphrasing Scott) the desire to provide clear concepts for developers that fit in with their existing conceptual fameworks (@scottaohara please disabuse me) Are there other reasons?

[scottaohara]

i said similar to that, but not necessarily in the context of needing 'subview'.

the reason i had initially thought we might need subview is so that we could make a distinction between a view that can be reached via consistent means (e.g., via a navigation) vs a subview that was more of a process that could only be reached via a specific view. That, and because we kept circling around whether a modal dialog was a view vs a component - and subview to me sort of split the difference.

i'm not feeling as strongly about needing 'subview' anymore, as we've talked through this more. What's a view vs what's a component seems more important to me than subdividing when a view is a view vs a subview.

[hidde-logius]

I liked subview intuitively, but feel we would be better off not including it. There is a lot of gray area and for many of our examples, the case could be made for stuff to be view or subview almost equally, I expect that confusion in our subgroup to indicate more confusion in the real world.

[stevefaulkner]

I think our current definition of View is a little wooly

View: Testing scope that includes all content visually and programmatically available at a given time, with the same purpose or for the same task.

Should "Testing scope" not be better cast as "Conformance scope" as it scope covers testing, user testing, design, remediation, developemnt etc. And they way UI is carved up for the testing is arbitrary, The important aspect is that the disected UI can be resconstituted to the entirity of a view for conformance purposes.

I also think that a unit for the purpose of conformance can be a view or a set of views, the concept of "testing scope" is misguided as what is defined as a sample for the purposes of testing could be a view or a set of views or a component(s) within a view.

with the same purpose or for the same task

This doesn't hold water as views (pages in old speek) may contain UI for multiple tasks or purposes

Also I am thinking that the definition of what a view is could be reinforced by reference to "change of context" term here (updated for WCAG 3) https://www.w3.org/TR/WCAG22/#dfn-change-of-context

[hidde-logius]

Agreed re comformance scope, have updated in our draft definition, and also agreed re ‘purpose’ and ‘tasks’ for th reason you mention and the one @GreggVan laid out in his response (could accidentally exclude bits of content, like ads).

I like where you’re going with change of context, will give it a think over next few days and see what others think.

[GreggVan]

I worry that words/phrases like "at a given time" "same purpose" or "same task" are very subjective and make the term VIEWS so ambiguous as to be unusable for normative work - or as a definition of SCOPE for evaluaton or conformance.

for example --

• are advertisments on a page part of the same task? IF not can they be inaccessible? what if they cause seizures. the "view" would still pass but a "page" would cause seizures.
• at a given time -- so as I scroll down - the page continually changes. So what is visually availabe is constantly changing. Are there an infinite number of views of the page? What if only two points in time (out of 100) show inaccessilbe content. Does that mean that that 98% of views are accessible - when the page is not and has a showstopper on the second view that blocks further progress?
• what does programmatically available mean. If content cannot be seen and is never shown - but if you use a software tool you can see it (maybe a database buried in the page) does it need to meet all of the guidelines?
• what about audio information? it is neither visual nor programmatic.

These are just 4 examples -- but there are many more like this. And none of these are near boundaries.

If VIEWS are to be the evaluation unit -- then VIEWS need to be unambiguous and objective - not subjective. Everyone needs to agree on what a VIEW is (or the VIEWS are) for every part of a website (or whatever is being evaluated).

PS I am a fan of VIEWs - and spent several months trying to make it work along with a team of others a decade ago but we never could. I see the same problems today as we saw then and have not seen any solution to them - yet. Still hopeful but ....

[hidde-logius]

Thanks for your input, Gregg, especially as you have so much experience in trying to make it work before. And thanks for being hopeful!

Some of your points relate to leaving parts of what is a page today out of scope, like advertisements or content outside of viewports. My assumption was always for all of such things to be part of the view (probably naive of me). FWIW. I don’t think of the view as the viewport (as in the CSS concept of viewport), but as everything on that page/screen/view. Might there be a simple way for us to include explictly in the definition that nothing is excluded, eg to avoid anyone claiming that their view would exclude ads or ‘under the fold’ content?

what does programmatically available mean. If content cannot be seen and is never shown - but if you use a software tool you can see it (maybe a database buried in the page) does it need to meet all of the guidelines?

for web content doesn’t this generally mean what’s exposed via the browser’s accessibility tree?

what about audio information? it is neither visual nor programmatic.

Good point

If VIEWS are to be the evaluation unit -- then VIEWS need to be unambiguous and objective - not subjective. Everyone needs to agree on what a VIEW is (or the VIEWS are) for every part of a website (or whatever is being evaluated).

I am not sure about this and would like to understand better why this would be essential.

Realistically, today, when 5 accessibility agencies create an accessibility conformance report for the same website, even if they all use WCAG-EM, it’s likely they’ll end up reviewing a different set of pages; the process recommends randomly selected pages. I think we’re generally okay with this, it’s more important that the auditors are diligent in reviewing the pages that were chose, that they are truly a representative sample, and that an assessment covers all WCAG violations to the best of knowledge.

I would personally be okay with differences in how auditor 1 and auditor 2 would split up a product, whether a website, app or VR experience, into different views. As long as that doesn’t mean they can purposefully leave certain parts out of scope, like the ads you mentioned.

Maybe I am missing your point or something else?

[stevefaulkner]

WCAG 3 a change of context

https://html5accessibility.com/stuff/2025/02/24/wcag-3-a-change-of-context

[LJWatson]

The term "view" makes sense to me, not least because it's a term likely to be familiar to developers (think webviews in native apps, views in Single Page Applications (SPA) etc.). I also prefer "conformance scope" as suggested by @stevefaulkner.

@GreggVan asked:

are advertisments on a page part of the same task? IF not can they be inaccessible? what if they cause seizures. the "view" would still pass but a "page" would cause seizures.

If I understand correctly, I think an advert could be considered a view in its own right or as part of a wider view. Adverts are typically served through iframes, so could be tested for conformance in their own right. They could also be tested as part of a view into which they're pulled.

at a given time -- so as I scroll down - the page continually changes. So what is visually availabe is constantly changing. Are there an infinite number of views of the page? What if only two points in time (out of 100) show inaccessilbe content. Does that mean that that 98% of views are accessible - when
the page is not and has a showstopper on the second view that blocks further progress?

I don't think the concept of a "view" is as literal as that.

My understanding is that on a classic website a page and a view may be synonymous.

If we stick to the use of "page" though, then every permutation of an SPA would be deemed a "page", which is unhelpful for many reasons. Within an SPA a view may be the part of the viewport that's updated in response to an event - which could, for example, be synonymous with the main content area.

In a native app a screen and a view may be synonymous, but a view may equally apply to a webview pulled into a native app wrapper. In some cases a webview might represent the bulk of the content, but in others it may represent a more tightly scoped portion of the screen.

what does programmatically available mean. If content cannot be seen and is never shown - but if you use a software tool you can see it (maybe a database buried in the page) does it need to meet all of the guidelines?

My take was that "programmatically available" was meant in the same spirit as "programmatically determinable" - as in available to tools that extract and present content to consumers.

what about audio information? it is neither visual nor programmatic.

If there was audio content within a view (or page or a screen), then it would be covered by those criteria intended for audio content wouldn't it?

[patrickhlauke]

Not sure if this has been discussed before, or how useful it may be, but: is it worth introducing the idea that a view is a discrete, self-contained "unit" of sorts? that it is distinct from other views? i guess that's implicit in the idea that it's a new "context", but worth making that even more explicit? (just reminded of the original problem of the old WCAG 2.x definition of web page, which was anchored on the very web 1.0 idea of "a separate page has a separate URI", which immediately breaks down in modern contexts with dynamic routing, or even form submissions)

[dotjay]

And herein lies part of the problem, at least for contexts like native mobile, where a "view" can be a way to refer to a discrete UI component rather than a full-screen "activity" within the "viewport". I had a go at defining a "screen" versus a "view" for use in WCAG2Mobile a little while back – not sure if it's of use:
w3c/matf#11 (comment)

[GreggVan]

On Feb 25, 2025, at 2:29 AM, Léonie Watson ***@***.***> wrote: If we stick to the use of "page" though, then every permutation of an SPA would be deemed a "page", which is unhelpful for many reasons. Within an SPA [Single Page Applications ] a view may be the part of the viewport that's updated in response to an event - which could, for example, be synonymous with the main content area.

Actually, think about it, it seems you have this exactly backwards If we stick with the definition of page — the app as a whole is the “page” just like an entire web app is a single “webpage” ( which is defined as everything you find at a URL with its support elements) what you propose (Views) is what leads to an infinite number of different things to evaluate since the “view” in an app is always changing with things coming and going (toolbars, ribbons, expansions, ) which are all independent and you would have to text each different combinatiion if you require all VIEWS to be accessible. There is also the case where one view may be inaccessible but the user can easily switch to another view of the same functionality and have one that is. But if all views much be accessible - then this accessible app would fail

In a native app a screen and a view may be synonymous,

what does “ may be “ mean? sometimes yes and sometims no? then how do I know when they are and arent? and are we using screen or view as the element of evaluation.

but a view may equally apply to a webview pulled into a native app wrapper

Now you are calling an entire webapp a “view”?

. In some cases a webview might represent the bulk of the content, but in others it may represent a more tightly scoped portion of the screen.

OK everything is possible. But what is the unit of evaluation and report. If it is to be used by regulatory bodies (like WCAG is) then you have to say WHAT it is that is being evaluated and passing or failing. And everyone needs to agree on what that is. Everyone (includign me) likes the idea of views. But everyone also has a different view or definition of what a view is.

what does programmatically available mean. If content cannot be seen and is never shown - but if you use a software tool you can see it (maybe a database buried in the page) does it need to meet all of the guidelines? My take was that "programmatically available" was meant in the same spirit as "programmatically determinable" - as in available to tools that extract and present content to consumers.

That sounds good but the way it is used - it does not match. You cannot plug the definition of PD into that sentence and make it work the way you want.

what about audio information? it is neither visual nor programmatic. If there was audio content within a view (or page or a screen), then it would be covered by those criteria intended for audio content wouldn't it?

Not if it is not included in your defintion of view — and view is the item of evaluation. in that case you evaluate noting but views - and audio is not in your defintion of views so it is not evaluated Now IF - you say - well the unit of evaluation is web page — and all the views and audio and any other non-visual information from the web page need to be accessible — then it works. but then everywhere in WCAG 3 where we have VIEW we need to put WebPage back or “vIews on a webpage” if we are talking about a web page that can have no audio (but I don’t know how you can confirm that.) that is the problem Start with “we need to say what the “unit of evaluation is” and then you can see that — although views is very attractive — there is no way to clearly and objecctively either define views (so that everyone will agree what all the views are for a page or app) — AND to not end up with an infinite number that defies testing. PS the fact that you can think of a simple page where it will work is not the test of an idea. It is when there are no examples of pages where the scheme falls apart (not counting something really bizarre that isnt realistic of course) Best g Still hoping someone will figure out how to make views work but seeing that all current formulations fail when you look carefully and try to apply accross all web pages (much less apps)

…

[LJWatson]

@GreggVan wrote:

what you propose (Views) is what leads to an infinite number of different things to evaluate since the “view” in an app is always changing...

The proposal to use "view" is a recognition of the fact that the term "page" is no longer fit for purpose, or at least, all purposes.

There are, of course, websites consisting of pages with unique URL, but it's been at least 20 years since that architecture could be assumed. The reality now is that the web and its broader ecosystem consists of multiple architectural permutations, and WCAG needs to use a term that encompasses most, if not all.

[hidde]

Agreed. Also, it seems to me a reductio ad absurdum to say that there is an unlimited number of views.

'Page', like 'view', is also not unproblematic. Sure, there are many permutations to what we consider views, but that is the case for most modern web pages, too. I don't know if a different word would make that problem bigger, if it is a problem.

[mbeganyi-a11y]

I agree with the two previous replies. I think primarily this will help to encapsulate a broader range of modern technologies and leave the concept of a fixed "page" behind. In some way, perhaps this could also provide a level of future-proofing, but I hesitate to lean into that as an argument for terminology. But I don't think technologies will revert to the concept of pages in the future.

[stevefaulkner]

@GreggVan wrote:

Start with “we need to say what the “unit of evaluation is” and then you can see that — although views is very attractive — there is no way to clearly and objecctively either define views (so that everyone will agree what all the views are for a page or app) — AND to not end up with an infinite number that defies testing.

Suggested definition

Conformance scope that includes all content visually and programmatically available without a change of context
I have tweaked the WCAG 2.2 definition of change of context and related definitions,

change of context

Major change in the content of the view that, if made without user awareness, can disorient users who are not able to view the entire view simultaneously
Changes in context include changes of:

• user agent;
• viewport;
• content that changes the meaning of the view.

A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, opening a non-modal dialog, or a tab control do not necessarily change the context.

Example: Opening a new window, opening a modal dialog, going to a new view (including anything that would look to a user as if they had moved to a new view) or significantly re-arranging the content of a view are examples of changes of context.

[patrickhlauke]

@GreggVan

There is also the case where one view may be inaccessible but the user can easily switch to another view of the same functionality and have one that is. But if all views much be accessible - then this accessible app would fail

the same way that in the 2.x "webpage" model you can have certain pages be inaccessible, but then have conforming alternate versions, the same concept would apply for views (whatever shape they take)

[stevefaulkner]

Perhaps we should rename view to unit so we don't get hung up on it...

[patrickhlauke]

or we can overengineer a new term, like "context container" ;)

[hidde]

Looking for prior art, I found the “web unit” definition from 2006.

[GreggVan]

Correct. Page and View are both problematic.

But page is defined and therefore usable. Again - I love "view" but it is not definable (or at least no one had figured out a definition that can be applied where everyone will come up with the same result when using the definition on a website.

Page is what you get from a URL meant to be viewed alone - along with all the the parts pulled into it in rendering.
if we use that as the element of evaluation - and point 20 people at a website with 30 pages and all will come up with the same 30 "units to evaluate"

point 20 people at a website or an app and aske them to give you a list of all the 'views' and you will get 20 different lists.

Let me call this the "list of evaluation units" or LOEU test. If we can come up with a defintiion of views as the evaluation unit (instead of page) and it can pase the LOEU text then we have solved it. Until then the 'views' concept is attractive, beautiful, alluring, etc. but it is not practical as an Evaluation Unit .

best

(Happy LOEU hunting)

[alastc]

Hi Gregg,

Firstly - could you keep an eye on where you are replying please? Adding a reply to the end of the page (or via email?) breaks the threading if you are replying to something specific. For several of your comments I can't tell what you are replying to.

On this:

But page is defined and therefore usable.

I strongly disagree, even just within web-specific technologies there are many cases where it just doesn't make sense anymore:

• In-between features such as modals, iframes, complex pop-over / slide-over content. These are also difficult to define with views, but at least we can take another run at that without the confusion of whether it happens to be at a different URL. (What the browser displays as a URL is almost completely arbitrary these days, the page could be a one-line script inclusion which draws everything in from multiple other domains.)
• Testing an SPA where essentially all the content & functionality is on one page (URL) makes it meaningless when comparing against something that is functionally the same, but split into multiple pages (as defined in WCAG2).
• ePub and PDFs, where (to a normal person) there are multiple "pages", but WCAG2 defines them as one page. Things like heading structure and navigation need to be different, so consider it multiple pages, but those SCs are fighting against the page definition.
• ePub which isn't at a URL, but it's still using web technologies.
• Kiosks displaying web content, but not the URL.

I have a similar experience to Patrick:

most auditors I know (which admittedly is only anecdotal evidence) ignore the old WCAG 2.x strict "a non-embedded resource obtained from a single URI using HTTP" definition when it comes to defining what a page is...

Also, if we can create a set of requirements that (others?) can extend to non-web applications, it's going to allow the requirements to be used more widely.

I agree that it would be best to avoid task/process for this type of definition. I think perhaps using a "perceived change of context" might be a better avenue to explore, I'm compiling (more) difficult examples in the sub-group's doc.

Overall, we really need to have a definition that makes sense in the modern web context, and to other digital technologies. Whether we redefine "page", define "view", "evaluation units" or (my flippant suggestion in the meeting) "purple zebras", I don't mind. But we need something.

[stevefaulkner]

@GreggVan

I love "view" but it is not definable

I find it diffcult to understand this as I regularly define the scope of native app sampling without issue.

point 20 people at a website or an app and aske them to give you a list of all the 'views' and you will get 20 different lists.

In practice I don't experience this, in fact it is often easier to define a common/agreed set of views for an app.

I cited a suggested definition of view in #286 (comment) but you have as yet offered no response.

As for your claim that apps have infinite views I just don't get your thinking on this

[patrickhlauke]

indeed, it may come as a surprise that even for websites, most auditors I know (which admittedly is only anecdotal evidence) ignore the old WCAG 2.x strict "a non-embedded resource obtained from a single URI using HTTP" definition when it comes to defining what a page is to deal with Single Page Applications (SPAs) and the like, at this stage already, and they seem to manage (maybe not completely unambiguously, granted) to break things down into logical "chunks" that are self-contained "pages"/"views"/"screens"/"sections of a website/web app"

incidentally ... while I appreciate the injection of some lighthearted tone, i can't help but shake the feeling that there's a bit of condescending mockery from certain conversation participants here for the necessary effort to bring WCAG's definition into the 20th century...[21st Century?] I'm sure it's not intended, but it's grating... (and yes, i realise the irony here, as i'm usually the master of throwing shade)

[hidde]

most auditors I know (which admittedly is only anecdotal evidence) ignore the old WCAG 2.x strict "a non-embedded resource obtained from a single URI using HTTP" definition when it comes to defining what a page is to deal with Single Page Applications (SPAs) and the like, at this stage already

(personal hat on)

this is my impression, too.

There are huge amounts of apps (and other things without pages) out there that people want to understand the level of accessibility of. That has been the case for years. Today, that's done by using a very generous definition of 'page' that ignores the bit about URIs.

I would like us to prioritise the ability to practically report on the accessibility of things over theoretically being more correct.

[GreggVan]

yes and I think that from a developers point of view-- view is a better thing to think of.

BUT if we are talking regulation -- then we have to have something objective. Think lawyers and judges. And conformance evaluations. For that we need something definite. I havent seen a viable definition of views yet (though I love the concept)

I suggest we spend less time talking about how much we like the idea -- and more time trying to find a defiinition that will allow us to use it.

best

[stevefaulkner]

@GreggVan #286 (comment)

I suggest we spend less time talking about how much we like the idea -- and more time trying to find a defiinition that will allow us to use it.

it would be helpful if you responded with concrete feedback

[yatil]

Most evaluations are based on sample. I agree that a view is a “you know it when you see it” kind of thing, but while there might be minor deviances when you ask professionals to select views as samples, I don’t think any choice would be invalid.

The reality is that testing by page has not been useful for a decade, and even with views I tend to have specialty buckets for common elements like headers, footers, and navigation. It’s just not practically useful to fail otherwise good views because of a missing alternative text in the heading, for example.

I honestly think it’s best to leave the term view open, with the boundary of “does not have changes of context” as proposed by @stevefaulkner and then give testers guidance on how to select valid samples through support material (see WCAG-EM for methods). Fixing the definition too narrowly, and you lose practicality and, when a new paradigm comes where the definition does not fit, flexibility.

[I reiterate my concern that WCAG3 is more concerned with “how to properly test WCAG3” than guiding people to make good decisions on what to test and fix issues. I have no interest to adhere to a stringent testing ritual to satisfy WCAG3, and I also don’t think clients will see the value. Testing needs to get simpler in a new iteration. Spending less time interpreting rules and doing the bureaucracy, not more.]

[alastc]

Ok, new versions incoming, probably easiest to read in the Views document, but I'll paste in copies below for reference:

1. Static element

A part of the interface that does not respond to user input and cannot be broken into smaller parts.

2. Interactive element

A part of the interface that responds to user input and can have a distinct programmatic name.

3. Component

A grouping of interactive elements for a distinct function.

4. User Interface Context

A user interface with a specific layout and associated components. If more than X% of the associated components are changed, it is a new “User Interface Context”.

5. Process

A series of “User interface contexts” associated with user actions, where actions required to complete an activity are performed, often in a certain order, and the entire activity is “under the control of the provider” regardless of the technologies used or whether it spans different sites or domains.

6. Product

A set of “User interface contexts” selected to be part of a conformance claim. Where a User interface context is part of a Process, all the user interface contexts in the process must be included.

Notes & context, please read!

• We may not need or use all of these definitions. We will see which are useful in the guidelines and conformance, and drop any that are not needed.
• The document includes examples under each definition.
• I have looked at industry ways of defining these types of thing (e.g. atomic design), but I haven't found one that works for our purposes. For example, separating interactive from non-interactive, individual things which need a name compared to component-groupings, and what would need a focus indicator.
• We (the editors) selected a coherent set of terms for now, but these are very draft.

The next task is to try them out. In your sub-groups, please analyse any requirements that would use any of these terms, and see if they work for that purpose.

[hidde]

Thanks for taking this further… the illustrations make it a lot clearer, so does seeing it together with the other related definitions.

I've added some questions in the doc to try and help to improve the definitions.

[JJdeGroot]

Thanks for the new version @alastc - left a comment in the doc for static element vs interactive element.

I like suggestion of @GreggVan to use interactive and non-interactive to catch all elements.

However, a video is now listed as static element, but it has controls. How to deal with 'static' content inside 'interactive' elements? E.g. carousel with images, video with controls, etc.

[GreggVan]

I think a video is 'non-interactive"
but the player is "interactive"

[hidde]

and in the context of HTML, a <video> is interactive.

[mraccess77]

One challenge with static elements being defined as not interactive relates to dynamically updated content that is not interactive. For example, content that is dynamically updated like a counter, heading, or chat message but it's not interactive. Calling it static content could create confusion.

[GreggVan]

Two comments

1. to address @mraccess77 -- how about we use non-interactive elements . That would also mean that between the two (interactive and non-interactive) we cover them all.

2. For static elements (non-interactive elements) you include "and cannot be broken into smaller parts." Is that neccessary? if so, then would every character in text be a separate element?

[hidde]

re every character in text: the document covers that (it says no they wouldn't).

[GreggVan]

@hidde Sorry -- the question really meant -- if we don't define objectively what a static element is -- we can end up with all sorts of things we don't mean to. And we can't exclude them by mention/list. We need a specific non-list definition of what the element means.

I think that non-interactive is easy because it both covers whatever isnt interactive (so we don't have a gap) and if we can define interactive .... then the definition is automatic.

[stevefaulkner]

may be helpful: interactive content definition in HTML https://html.spec.whatwg.org/multipage/dom.html#interactive-content

[alastc]

I'd love to use someone else's, but the HTML one is "content that is specifically intended for user interaction". I'd rather something concrete that wasn't based on "intention", otherwise the author could game the 'intention' aspect. (And it's confusing for external testers.)

[hidde]

Agree intention is pretty vague.

There's a large crossover between people who will use WCAG and people who know HTML, a definition that is somewhat similar but not the same could lead to a lot of confusion.

We could work with WHATWG to propose changes that don't rely on intentions?

[alastc]

Summary 6th May 2025

We've been using a survey to track comments and whether sub-groups have tried to use the terms yet.

The comments included:

• A suggestion to add to the component definition "when used together", and leave out the "interactive" aspect. i.e. "A group of related elements which when used together perform a distinct function."
• Support for using "non-interactive" instead of "static".
• Are disabled buttons / read-only fields considered interactive? Often they are focusable. Does copy-pasting text make it interactive? Is a read-only radio-group a component?
• Unsure of whether "distinct programmatic name" = accname.
• Can a component include static elements?
• Comment about "the context may not change on focus not on input." @gundulaniemann - I didn't understand this paragraph, could you clarify please?
• When is a layout specific to a UI-context? What are the components associated to?
• If you think about a "product" as a 'selling unit', it might not cover a process. I.e. several products are required to complete a process, the vendor might not be able to do a conformance statement for that.
• The inputs subgroup found to much friction with "UI context" and reverted to page/view. Also, might be missing a "set of pages" concept.

[gundulaniemann]

Summary 6th May 2025

• Comment about "the context may not change on focus not on input." @gundulaniemann - I didn't understand this paragraph, could you clarify please?

I was referring to https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html and https://www.w3.org/WAI/WCAG22/Understanding/on-input.html which certainly will re-appear in some form in WCAG 3.
Talking about a change of context implies talking about context, so the definition needs to fit the purpose of talking about that a change of context may not occur on focus neither on input.

[GreggVan]

Thanks @alastc

my comments on the comments. (I still love the idea of views -- I just can't make it work...)

• A suggestion to add to the component definition "when used together", and leave out the "interactive" aspect. i.e. "A group of related elements which when used together perform a distinct function."

Doesnt this also apply to any web page or whole app or even website? e.g. Shopping sounds like a distinct function. Are we just kicking the can to the definition of "distinct function" (in which case we should just put those words in here.

• Support for using "non-interactive" instead of "static".

+1 on this. that would solve so many problems, make the defintion easy, an resolve the question (what about things that are not static and not interactive. if one definition is not the negative of the other -- there will always be things that miss both.

• Are disabled buttons / read-only fields considered interactive? Often they are focusable. Does copy-pasting text make it interactive? Is a read-only radio-group a component?

Good question.

• disabled buttons - yes they are interactive elements that are disabled
• read only fields - no content but not interactive (according to the commonly used definition of "interactive element" - no?)
• copy pasting elements are interactive but text that you act on is not
• read-only radios group -- if it is disabled - yes. if it is just text that can never be interacted with.

Another question is " is editable text interactive ? or it just the field that is interactive?

• Unsure of whether "distinct programmatic name" = accname.

answer - NO. that is one technique. And does not work everywhere. AND we want to be futureproof and what is programmatic in the future (With AI based AT or browsers) may be VERY different.

• Can a component include static elements?

Good question. depends on definiton of component? I think it can because a paragraph is a component of the page content?

• Comment about "the context may not change on focus not on input." @gundulaniemann - I didn't understand this paragraph, could you clarify please?

I think it means that just focusing on (moving the keyboard focus -- or hovering where allowed - should not cause the page to change to a new context (or it is a landmine and you can't get past it when using keyboard focus because when you hit it with keyboard focus the context you are in suddently changes. This is why popups or dropdowns are not considered changes in context.

• When is a layout specific to a UI-context? What are the components associated to?

The problem here is - we have not yesterday found a stable definition to "UI-context" so we can't stablely answer this question (and all the other)

• If you think about a "product" as a 'selling unit', it might not cover a process. I.e. several products are required to complete a process, the vendor might not be able to do a conformance statement for that.

I think "product" is a bad term. Maybe we should stop at "scope of conformance" or something. otherwise I don't see us ever coming up with a stable name and definition for this level.

Agree that product is not a good term. does sound like something you sell - or that could be sold.

• The inputs subgroup found to much friction with "UI context" and reverted to page/view. Also, might be missing a "set of pages" concept.

We decided to use page/view because that allowed us to read the sentences with both words in place to see if they would survive if either approach was used. we used view instead of UI-Context because it was shorter and stood in for the concept -- not because we thought View was better than UI-context as the final term.

[alastc]

Update 20th June 2025

I've tried to come up with a workable solution for these definitions, and come to the conclusion that "view" does fit some web page contexts, and "page" does fit some web-app contexts.

So why not both?

In the draft definition 3 tab (direct link), I've gone back a couple of versions for the "view" definition, and added the web-page:

View: An interface with a specific layout and associated controls. Changes to the available content are considered part of the current view if the layout is maintained and the associated controls are still available.
Page: a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together.

I've also added a note that basically says: These are both units of conformance, use either or both.

That mildly cascaded to the process and conformance-scope definitions.

[hidde]

I like where you're going with this. Let's test it in various environments, like success criteria text and WCAG-EM, but my feeling is this will be helpful way of going about it.

[GreggVan]

I like the idea of not making it an EITHER ONE OR OTHER situation.

But I think the View definition still needs work.

Lets say I have a header with my logo and search on it.
Then below it I have 15 tabs. Each tab changes everything below.
That fits your definition of View but is in fact an entire website. So View=Page
Ditto for a web app. The definition does not say how much of a "view" needs to change before it is a new "view".

That is how the definition reads to me. Am I missing something?

PS And if we did say how much needs to change before it is a new view, we just create a new problem. If we say 25% then something can be a new view one day - and the next -- when they add a period (or a sentence or a paragraph) to the base side - it no longer is a new view?

[hidde]

Agreed that trying to say how much needs to change leads to new problems.

I'd like us to not define exact boundaries. It's impossible to get right, but also unnecessary. In practice products (websites/apps/kiosks) have natural boundries and people can figure them out, just like they do today when they apply WCAG to non-web.

[GreggVan]

I am afraid the "i'll know it when I see it" approach is not good enough for a regulation. if it is "everyone will know where the line is and put the line in the same place when they see it " then that is good enough. But for a standard to be objective - and for something to be used in regulation - we need a definition where everyone will place the line in the same (or almost the same) place. That is -- there can be a little fuzziness right on the border (even a line in the sand has edges - and the grains in the middle... are they this side or that) but so far our definitions of view have people judging the change in view all over the place -- even when they agree it sounds like a great idea.

I love the idea - but - AS YET - have not seen or been able to come up with a definition for it that holds water when you actually try to use it. They all are full of holes. We keep trying, but we should not just assume that trying will mean success. So we must also have a fall back plan if we never get there.

[hidde]

But, as you know, WCAG is used for regulation today, including for regulation that sets requirements for app and kiosk accessibility. Accessibility professionals today are knowing it as they are seeing it, by which I mean applying WCAG to non-web even if WCAG criteria apply to web pages.

At the government I work for, we see reports about app accessibility that test WCAG and that use WCAG-EM all the time (even if those apps don't contain web pages). We're seeing professionals are able to make the judgments on this level. Sometimes with the help of our supplementary guidance (eg WCAG2ICT, the WCAG2Mobile draft).

Escaping through loopholes does happen, but on different levels, and through different and much larger loopholes.

[GreggVan]

@hidde I agree

but not sure what that has to do with my comment. I was saying (or trying to say) that if we want WCAG3 to be cited in law/regulation etc. as much as WCAG2 then the unit of conformance must be clear and objective - and not up to subjective judgement.

I think non-normative docs (take the cognitive doc for example) are fantastic resources and are used by authors. But authors (or author's companies) should not have to suffer consequences (i.e. regulation) for not following a requirement where it is vague enough that they might do what THEY thought was required but someone else could judge it differently and have that other persons judgment be accepted. In other words -- an author should, with confidence know when their work passes or not.

that is the only point I was trying to make.

best

[GreggVan]

@hidde I agree. And 508 and EN 301 549 both use WCAG for docs and software as well - using WCAG2ICT as a guide.

But I don't see what that has to do with the current discussion about the fact that "views" does not have any clear unambiguous (objective) definition where people agree on exactly what constitutes a view - and a new view. Am I missing something?

[stevefaulkner]

The issue of concern is not one of how do we slice a web site/webapp/app/ebook/pdf into managable portions for testing purposes/conformance purposes. The conformance of a web site/webapp/app/ebook as a whole is the issue. slicing by the current page definition does not provide the clarity and conciseness that @GreggVan craves, but it has been used as the basis of a normative definition in WCAG for yonks.

does not have any clear unambiguous (objective) definition where people agree on exactly what constitutes a view

We have in page transitions and whole web apps that consist of a single page a single URL. Which can be applied @GreggVan describes as an ambiguous view below:

Lets say I have a header with my logo and search on it.
Then below it I have 15 tabs. Each tab changes everything below.
That fits your definition of View but is in fact an entire website.

The important thing (I think) is that conformance with WCAG means that a user can successfully achieve what the purpose of the website/web app/app/PDF/kisok is designed to do, not how its is sliced up for testing purposes.
So for a shopping site, the question is not whether 1 or 20 or 1000 defined slices of the site are WCAG conformant or not. The question that WCAG conformance should be an answer to is whether or not the site UI allows users to successfuly purchase the item(s) they want. How the answer is acheived, either by thin or fat slicing it is irrelevant.

[hidde]

@GreggVan: the relation between 508/301549 using WCAG and current discussion is: the status quo is already that people (need to) use common sense for slicing up (to use Steve's phrase).

You are claiming common sense is a problem for regulation because not objective, I am claiming it is not a problem, because practitioners have already been doing common-sense-based slicing up for years. They've had to, because regulation effectively required conformance claims about apps/kiosks/documents, and WCAG was the most useful standard for it, even if that involved somewhat creatively ignoring the fact that it concerns web pages and apps (which, you know… I think we all agree is not as objective as we would all like it to be).

The status quo, even with its level of subjectivity, and even though I appreciate you it call out, hasn't been a problem for monitoring. As far as I can see, anyway. Judges in many jurisdictions look at the bonus pater familias principle / common sense. Reading, for instance, the reports on monitoring from the European Commission, I see no mention of this specifically being a problem.

I might be missing something though… maybe you know of government bodies that did specifically find that this hinders their ability to monitor or regulate? Or from conformance evaluators / accessibility consultants that expressed a need for specific rules around slicing up?

[alastc]

Update: June 26th

Based on feedback I've updated a couple of things in the draft definition 3, and we can discuss in the next meeting.

The changes are to View:

An interface with a specific layout and at least one component that is maintained whilst interactive elements are used to change the content within the layout.

So the idea is that, instead of trying to establish a level of change, we look for at least one component which is maintained whilst the content of the page changes. A logo-link would be an "interactive element", but it would not qualify as a "component". So you'd need a nav-bar or something, where you can select items from that and the content changes.

I also updated the note, which I think will need to go in the conformance section rather than under each conformance unit:

Note: A conformance claim can use Views, Web Pages, or a combination of both.
Where a URI is available and represents a unique set of content, that would be the preferred conformance unit. (I.e. the layout and content do not change significantly when the same URI is shown.)

I also dropped the term "product" and went with "conformance scope". In my work "product" is synonymous with any website, or part of website, or app as they are created by "product teams". However, in other places (such as the EN 301 549) product is more strictly about hardware, so would be confusing.

[GreggVan]

@alastc -- OK I see some problems with that -- but actually no more problems than would occur (do occur) with our web page as conformance today. So remove that from the list - but what about the other bits? e.g. TABS or things that change minor parts of the page where it does remove things? (again - hoping you have an answer to these issues I can't solve)

[patrickhlauke]

@patrickhlauke I don't follow your answer. You seem to be saying "all those can be a "view" depending on context". We can't use view as a conformance model if it has no fixed definition. if the definition is -- 'well it depends" unless you can say exactly what "it depends" means in a way that formulaic. -- that everyone can just apply the formula to the situation and they will all come up with the same answer

which answer of mine are you referring to here? your reply is not on anything i've said. please use github's proper reply option to relate your comment directly to what you're replying to, as otherwise the threading becomes incomprehensible (as in this case)

[hidde]

@GreggVan sorry, where did I mention authors?

And please don't keep lecturing me about regulators as if I simply misunderstand your view. These things are quite different country by country, in many places outside the US accessibility conformance discussion don't really happen in courts.

I'd suggest we survey some regulators worldwide to figure out what they want out of this, and it it includes objectivity in this area, I don't want to make assumptions and then overcomplicate things for everyone involved.

[GreggVan]

@patrickhlauke
this is the one I was commenting on (above in this same thread)

patrickhlauke
12 hours ago
Collaborator
i know i've banged on about this at length earlier in the thread already, but to me the key really comes down to "context". whatever the user perceives as a separate "context" - a new page, a modal dialog, a modal slide-in side panel, a different "page" in a single-page app...anything that effectively creates its own self-contained portal/realm/context/universe/world/whatever, and it's made to work as an independent "thing". yes, there will still be cases where the independent contexts share some common components/elements (like an SPA where the header/navigation bar and the footer remain the same, but the bulk of the content in the middle makes it a whole new context

(as for the earlier listing from gregg about "all pages in the smithsonian / each single page on the smithsonian site" yes, those all act/work as separate contexts; whether you want/can test them all is a question of WCAG-EM sampling of course)

[patrickhlauke]

this is the one I was commenting on (above in this same thread)

so where in that am I seemingly saying "all those can be a "view" depending on context"? that's what made me think you're actually replying to something else.

you seem to be misunderstanding my (and others') use of "context" here ... or at least have not engaged with it despite it being mentioned repeatedly in the thread. nobody's saying "it depends on context". we're saying that a page/view/portal/unit/galaxy/pocket universe/whateveryouwanttocallit is something that has a self-contained context (in the same vein as the existing change of context definition)

anyway, i'm done with this circular argument back and forth

[GreggVan]

QUESTION: Is a dropdown menu itself and interactive element (an not just the items in the menu?) I would think yes - but your definition here does not cover it as Interactive or non-interactive. It is a component I know - but it still has to be interactive or not. Would say it was interactive. Also and expanding paragraph is interactive. (not the paragraph but the expansion element that you click on to expand it) no?

[GreggVan]

you seem to answer the question with
" Mostly those are "interactive elements", as they do something when the user selects them, either opening a drop-down or activating a link."

so you are saying that something that opens a drop down - is an "interactive element"

So components are interactive elements that contain other interactive elements.

That is fine and works.

If components like dropdown menus were NOT interactive elements -- then we would have a problem. it would mean that you could not tab to a dropdown menu because it was a component and tabbing only moves you to interactive elements. (and a bunch of other similar problems).

So components and interactive elements are not part of a hierarchy. ( all interactive elements are not part of components) but rather components are a type of interactive element that can include other interactive elements.

(this also solves the problem of whether a menu bar is a component or with menus with submenus and interactive elements (e.g. a "menu" on the menu bar with no dropdown menu but just a direct link ) or it is a collection of interactive elemtents some of which are direct links and some of which are menus with interactive elements some of which are links and some of which are submenues (that can also include links or sub-sub menus - both of which are interactive elements)

compontents that are menus with interactive elemetents

[hidde]

components are interactive elements.

Agree?

I disagree and would like us to stay away from this, given how authors, who are not the only constituent, but are decisive in how accessible any web content is, define components. It is very common to have components that don't contain interactive elements.

[alastc]

@GreggVan - we have definitions in the doc for both, so interactive element is:

A part of the interface that responds to user input and can have a distinct programmatic name

From experience with focus-indicators, it's best to avoid having a nested approach, as the parent may not be focusable in itself, and it makes writing the requirement more difficult. ("Sub-component" was a bit of a bodge in WCAG 2.2 for focus appearance, a clearer definition of interactive element & component would have helped.)

you could not tab to a dropdown menu because it was a component and tabbing only moves you to interactive elements.

I don't think you do tab to a "dropdown menu". You tab to the first interactive element within the drop-down menu, i.e. the first link/button.

@hidde - again, I know you don't like us using the word "component", but I've yet to see a better term, and we have to use something.

[hidde]

In the route I propose we don't need to define components or interactive elements.

I don't understand the current route or the goals for it sufficiently to comment on what would be a suitable
word instead of component, but hope my objection can still be taken into account as part of the consensus process.

[GreggVan]

@alastc

1. yep your definition of "interactive element" works perfectly for menus. You certainly interact with them.

2. If you can't tab to the menu but only its elements -- then how do you tab past it?

A basic premise of keyboard navigation is that you NEVER want to have a menu auto-open-and-highlight-the-first-item when you tab to it. That would mean that you would have to tab through every element of every menu and submenu and subsub menu and subsubsub menu etc. before you could get to past that menu if you just wanted to get to something after it. In fact doing what you say is actually a failure. you want menus to move into a menu when you activate it. (click on it or hit spacebar to activate it ) otherwise you can't tab across the third menu to use it without exhausting all the items in every menu (submenu etc) before it.

Make sense now?

[alastc]

Sampling

Hi everyone, I've added the previous examples with my interpretation to the bottom of the Definition 3 tab.

Also, in going through that, I want to make a point: In practice, the definition of page (or view) is not as important as how you sample.

We know at the moment that the page definition is often ignored in practice, for example:

• People fill in VPATs (including for EN 301 549) for products which don't have URLs.
• At least two well-known accessibility-testing companies use "components" as the basis for sampling, not pages.

In practice, getting a good sample of content-types and interactive-components is way more important than the page (or view) definition.

The key to sampling is to analyze what component are available (via a design system, and/or automated review, and/or manual review), and ensure you capture an example of each thing.

So I'm +1ing Hidde's point that we can allow for some common sense interpretation of these definitions, it has been happening for years already.

I don't think we can (or should) include sampling methodologies in the core spec, but can we agree to reasonably open definitions of page and view with a caveat that we will also need an informative doc to outline sampling methods (like WCAG-EM)?

Aside from conformance, the definitions (including "closely available") need to work for whether something is available in the same context, and I think that works with the current definitions. We'll need to work on that more anyway, as the content comes together.

[GreggVan]

@alastc
in answer to your questions.

For example, show people a kiosk or SPA, and would they all say "it's one page"?

• A Kiosk is not a web page. If it did display a web page (it was basically a browser) then the definition of web page (all associated with a URL etc) then all 20 would agree - since it is clear and has only one interpretation.
• if by SPA you mean Single Page Application - it is clearly a web page. And all 20 should agree. It is even in its name.

What about the proposed approach and definition?
Have both. Use page if you have separate URLs and view if you don't.

• I love the idea of using both - but ONLY after we have an objective definition for View. Without that we can't use it on any provision. Since no one will know (or agree) what it means in many real world applications. The definition you propose sounds good til you try to test it. I gave a bunch of examples before. It would be a good test to have a blind survey (where people can't see other people's answers) and see if using this definition (most ) everyone comes up with the same judgements. I have not seen that in discussions to date..

View: An interface with a specific layout. If the layout includes at least one component that is used to change the content within the layout, that is part of the same view.

[alastc]

For both kiosk (showing web pages) and SPA I strongly disagree, I don't think the answers about "page" would match the definition.

It can be clear, objective, and useless at the same time!

I added an email app example. The graphics are from a native app, but the web-app of my email is the same structure, I just don't want to share my main email.

I would bet that more than 66% of testers, and probably general public, would categorise at least three of the four screenshots as separate pages or separate views, whereas (by the web-page definition) they should be one.

[GreggVan]

@alastc

If they don't have the definition of web page -- yes they might. But that is not relevant. The test of testability is whether multiple evaluators who are knowledgeable of accessibility guidelines would make the same judgment. They have to be qualified judges -- which would mean they need to know the definitions.

You also talk about "Pages". We don't have a definition for page. nor any discussion of pages. Just web pages.

you also talk about an email app. We are talking about web content. If you want to talk about non-web content then we need to start all over and rewrite many of our requirements because they assume a user agent -- and non-web content does not have one.

Finally - you talk about "screen shots". You can't tell anything from a screen shot. You have no idea where that came from. A web page - a web app, an app, a mockup, a drawing. If you try that approach and ask are these the same or different views - I think you will find the same large disagreement.

If you want to use Views (I do) then we need to come up with an objective definition. Arguing against web pages won't get us a definition we can use for views. And web pages are objective. They have other faults but they are valid objective units for evaluation. So that is the only thing we have that we can use now. Lets work on getting a definition for Views. Then we can use your hybrid approach (using pages or views as appropriate) - which may be a great idea. But not if we don't have an objective definition of views that works.

[patrickhlauke]

you also talk about an email app. We are talking about web content

web-based email clients like gmail do exist....

as @alastc points out clearly in his comment:

I added an email app example. The graphics are from a native app, but the web-app of my email is the same structure, I just don't want to share my main email.

[alastc]

The test of testability is whether multiple evaluators who are knowledgeable of accessibility guidelines would make the same judgment. They have to be qualified judges -- which would mean they need to know the definitions.

Yes, but in practice, they (including me) don't make a judgement which aligns with the WCAG 2 definition. It is ignored, worked-around.

NB: In the above discussion "page" is short-hand for the current WCAG 2 definition of web page.

If you want to talk about non-web content then we need to start all over and rewrite many of our requirements because they assume a user agent -- and non-web content does not have one.

Indeed, we are doing that!

Finally - you talk about "screen shots". You can't tell anything from a screen shot. You have no idea where that came from. A web page - a web app, an app, a mockup, a drawing. If you try that approach and ask are these the same or different views - I think you will find the same large disagreement.

I talked about the sceenshots I took of a real app (that could be a web-app), and told you where they are from. It was a visual aid (with alt text) to show the type of scenario I'm talking about.

You could install the app (or open the web-app) and get the same thing I screen-grabbed. That's a tangent, my point is that in practice, the definition of "Web page" is completely ignored for that type of native app / web-app.

If you want to use Views (I do) then we need to come up with an objective definition.

I agree, but I really want you to understand that the current web-page definition does not work in many cases where we need it to. We have lots of evidence that it is completely ignored for whole categories of product/service, in those cases "web page" is not "a valid objective unit".

So the current question then is: what is not objective about the proposed definition?

An interface with a specific layout. If the layout includes at least one component that is used to change the content within the layout, that content is part of the same view.

[alastc]

Summary 1st July 2025

There is an updated definition, and examples of how it could be interpreted.

There has been discussion about what constitutes an interactive item. It does not seem to be a blocking discussion.

Quite a few people have made points about how the current "page" definition is interpreted, not according to the exact definition but with a common-sense approach. Why shouldn't the view definition use the same approach?

A key point made is that a standard picked up by regulation needs to be clear and objective. For example, showing people the definition and a variety of interfaces, and people would mostly agree on what would be view (or page).
There is disagreement that "Web page" currently meets this test.

This aspect needs agreement before we can progress.

[GreggVan]

Quite a few people have made points about how the current "page" definition is interpreted, not according to the exact definition but with a common-sense approach. Why shouldn't the view definition use the same approach?

because it isnt a valid approach for web pages. Yes people can make up their own definitions for what constitutes a web page. And they can find them useful. But they are not all the same. And being useful (untestable recommendations are useful - very useful) is not sufficient for using them in regulation. You can't use something in regulation that does not have a definite meaning - that when applied - provides the same answer.

A key point made is that a standard picked up by regulation needs to be clear and objective. For example, showing people the definition and a variety of interfaces, and people would mostly agree on what would be view (or page).
There is disagreement that "Web page" currently meets this test.

There is opinion that it doesnt meet the test. But I have not seen proof. All the examples I have seen were with people who used their own definition of web page - not the real one - and then argue that it (their personal definition) did not yield repeatable results.

If people are making assertions like that - they should accompany them with examples where people following the real definition come up with significantly different results. Is there such a collection of examples? that would be most useful in this discussion.

[hidde]

All the examples I have seen were with people who used their own definition of web page - not the real one - and then argue that it (their personal definition) did not yield repeatable results.

It is common practice in reality that people use their own definition of web page, for instance a majority of all organisations that (a) have apps, (b) are required to comply with (their local implementation of) Directive 2016/2102 will test apps while ignoring the literal definition of web page.

I'll repeat what I said in the meeting yesterday: this is mostly not a problem for anyone. It works (kind of).

It works for monitors who can now have an impression of the state of accessibility, it works for end users as orgs are able to find barriers and remove them, it works for auditors as they can report problems in their apps/kiosks/etc, it works for teams building those things.

We can make it somewhat better (and we should). View will help with that. But the lack of repeatable results for a simpler view definition, that I agree exists, does not pose as big a problem as you make it out to be. This is evidenced by the status quo in which we have a lack of repeatable results for (granted, people's own interpretation of) web pages.

[patrickhlauke]

There is opinion that it doesnt meet the test. But I have not seen proof. All the examples I have seen were with people who used their own definition of web page - not the real one - and then argue that it (their personal definition) did not yield repeatable results.

If people are making assertions like that - they should accompany them with examples where people following the real definition come up with significantly different results. Is there such a collection of examples? that would be most useful in this discussion.

starter for 10 ... a site that has lots of content pages, all with very different content. but it happens to be built as an old-school SPA where nominally the URL/URI doesn't change - all content is loaded dynamically. now, assess that against 2.4.2 Page Titled ... if you follow the formal (inadequate) definition of "Web Page", all that's sufficient to pass is that the SPA has an initial title ("My SPA site"). What happens now as a user navigates to the various other content "pages" and the title doesn't change? Taking the formal definition (it's all under the same URL/URI), that's a pass ... and it shouldn't be, because the title does not reflect the actual content that the user gets to.

(and yes this has been partially addressed/clarified in the non-normative intent in the understanding document recently https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html ... but of course that doesn't normatively hold, and it introduces a "should" by the backdoor which it...shouldn't do)

[alastc]

@GreggVan

There is opinion that it doesnt meet the test. But I have not seen proof.

Any VPAT or EN301549 report for something that doesn't have URLs is not using the web page definition. The public report wouldn't show it, but if you can dig into the sampling and audit work behind that, it will not even consider the definition of web page (which basically includes everything).

The example (elsewhere in this thread, somewhere!) from the email app, which is also a web-app, shows 4 screenshots.

I'd bet you dollars to donuts that the official definition would be ignored by >90% of professional testers, and each of the screenshots would be considered a separate view/page/thing. But officially it should be one "page".

Maybe in the phone call later I can take you through some examples I can't make public.

(PS. is the "dollars to donuts" still useful, or is a donut more than a dollar now!?)

[GreggVan]

@patrickhlauke

OK take your example. The definition is that everything that comes from a single URL is a web page. Therefore (like a web app) that entire collection of things is a web page. There is no ambiguity.

That is what I said. There are problems with the current web page definition. But if you know (and apply) the definition - there is no ambiguity.

If they don't change the title - or have a bad title for the collection of content- that is a failure of the SC. But it is not a failure of the definition. Nor does it make the definition ambiguous.

What they did may make it hard to conform to WCAG. There are dozens of other bad practices that can make it hard as well. But that is irrelevant to the question of whether the definition is ambiguous.

To repeat: There are problem with using web page as our (only) unit of conformance. (There are problems with everythign including democracy) But ambiguity isn't one of them. We are looking at Views because we see advantages to it. But we need to have an unambiguous definition for it. and we don't have one.

Why do we need an unambiguous definition?

1. (the one we always hear) is because regulatory standards require it. Otherwise one doesnt know when one has passed.
2. because, when it is ambiguous, different people will interpret it differently -- so we create requirements (SC's in old speak) that people may agree to because they interpret it one way and another agrees because they interpret it another way. So we agree when we don't agree. And then later we find out it REALLY means something else -- to someone else -- and so we can't rely on being right. And then there are endless arguments later as to whether it means this or that.

We need to figure out now what we mean. And we can't use a word we can't define in a way we all know what it means.

[detlevhfischer]

I think the decision yesterday to go with the (in my view hard to understand) definition of "view" is a grave error that should be corrected. This is the current definition with most people plus-oned (is that a word?):

An interface with a specific layout. If the layout includes at least one component that is used to change the content within the layout, that is part of the same view.

That creates a big practical problem. In the evaluation of mobile apps, it should be possible to allocate conformance errors to particular views / screens, i.e. where they occur, regardless of whether these views share elements like a navigation bar with other views. If we seriously say: if there is any element (such as such a nav bar) that all screens share, then all these screens are lumped together in the same view, we end up amassing a broad range of issues under a single view, having to spell out in reporting to which screen of that monstrous view an issue belongs. That is not helpful. And if this turn leads to defining individual screens as components, i.e. components then being the actual units that are evaluated, you wonder what the aggregate of "view" is then good for. The only advantage would be to focus on the element(s) shared by all screens under that concept of a view (say, the navigation bar) but that I believe is not intended in the current definition.

[detlevhfischer]

How do you do that now? I.e. where the "web page" is the conformance unit?
Presumably the whole app is one unit? At least, it is supposed to be under WCAG2.

where the web page is the unit we have the URL and specific results, and list content that spans across many pages as general result for that span of pages. But my point is that with native apps without URL you have a similar situation: apart from shared navigation (sometimes also shared header) 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 (and, like with web sites, shared issues as general comments or comments applicable to a span of pages).

If not, how do you currently sub-divide it?

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.

The utility of the conformance-unit is more to do with ensuring that a chunk of available content is included.

I am not sure what that means. 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.)

We could take a thin-slice approach (e.g. all the available interface until there is new or removed content). But you'd have a lot of views where most of the content is identical.

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.

The one thing I don't think we can do is take a percentage of content (or controls) as the change measure. (e.g. the interface that is available until 50% or more of the content changes). It would be too complex to do, and the fickleness would lead to odd results.

Agree that is does not work to calculate the amount of change. The point is qualitative. You just want to ensure you include all different components there are. I do not see how that introduces fickleness or odd results. 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).

[alastc]

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.

[patrickhlauke]

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.

Do they create their own context - meaning that they act as self-contained "things" (keeping focus inside themselves, making the underlying page that spawned them inert and hidden). are they modal (even to the point, particularly on small screen views, where you don't even know as a user that they're a modal, because they're screen-filling, so really looks like you moved to another full page)

[detlevhfischer]

@alastc
Just picking out three things:

And talking about different components is about sampling, not the conformance unit.

In WCAG 2, the page is the conformance unit. Sampling pages (with distinct URLs) gives you as many conformance units as pages, so there is historically a strong connection. In native apps (and web SPA) you need to define the page yourself (usually the result of a sequence of actions based on a base URL), so in a sense you establish the units of conformance yourself and treat those units like a page, and it works. So I think that as much as possible conformance units should equate sampled pages or views.

There is some scope in either lumping things like pop-ups together with the parent page on which you trigger them, or treating them as independent units (as Patrick pointed out, depending on the viewport size they may take up the whole screen), and there is no harm with either approach. The main thing is that sampling ensures all content is covered and all relevant issues are reported - whether on one screen with its children or separately does not make a significant difference in terms of the overall result, at least as far as the conformance on the level or product or service is concerned.

Reporting by screen would be very repetetive, as the same issue would apply across many screens.

That's why we would record repetitive issues just once (as one issue) and marking the pages where the issue is present. And in sampling we would avoid including several similar pages/screens unless they have diverging content which warrants their inclusion. If one page has text only content and the other text and a set of disclosure widgets, we'd take just the second one.

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.

Since we tend to follow the idea of the page as conformance unit as closely as possible, we would usually not sample by content type and functionality unless we evaluate things like a design system (where you typically could not really state conformance since you look at stuff in isolation and only report on applicable SCs - leaving out things like 2.4.2 Page titled, 2.4.5 Mulitple ways or 3.2.3 Consistent navigation).

[detlevhfischer]

Another try:

View:
A particular chunk of content that either fills the viewport or renders content underneath inert, including areas that can be scrolled or panned to and including any additional content that can be extended or brought up on top of it without replacing it.

[ChrisLoiselle]

Hi, in terms of the word "view" I have some clarification questions that I'm asking below, they may have been already answered within the thread, or on a AG call and within minutes of that meeting. If they have , I apologize in advance for my oversight, if you could point to answers elsewhere, I will read up and take my comments offline. Here are my thoughts:

1. Are you stating that someone would validate one "view" vs. "one page/screen"?

2. Does one "view" mean both landscape and portrait "views" within that "view" ?

For example, in terms of view, how would this be applied to say iOS, iPadOS, MacOS, VisionOS, WatchOS, Games, where there may or may not be web user agents involved that display context in an user agent on the device vs. where the interactions are solely on native iOS apps?

3. Is the expectation that the person evaluating their set of "view(s)" already has a list of known views that they are going to validate?

4. Does someone start evaluating a given product for WCAG , come across the Orientation SC and then expand their "views" to incorporate both landscape and portrait "views" within their "views"?

5. Are you specifically just mentioning "view" in terms of view port size and how this showcases in an user agent within a specific device?
   For instance, how I access Gmail (or any other application) on a mobile (iOS) device within / on a browser differs from how I would do so on a laptop device per available space to showcase that "view". Same could be said for an iPad's use case.

6. If someone uses https://developer.apple.com/documentation/safari-developer-tools/responsive-design-mode for example when validating their design, should they be using using the simulator menu to review "views" and create a list of what views within "views" to evaluate ?

7. Will our definitions of view deal with simulators at all? I.e. , https://developer.apple.com/documentation/safari-developer-tools/responsive-design-mode#Open-with-Simulator ? Are we just leaving all of this to content authors who may be developing views for Apple content?

8. Is the use of the term "view" adding to confusion whereas vendors such as Apple already use "view" per their dev specs and design guidance? Do we want to phrase this more clearly for content authors so they know what to uptake per our definition of view?

9. If W3C AG decides on view terminology, how would that impact WCAG2Mobile, non-web software and non-web documents, i.e. WCAG2ICT?

10. Should AG within WCAG 3 look more toward ICT and then web, non-web? I.e. mobile first mentality on content smaller viewports / screens and gradually reporting on how content "views" are showcased on larger viewports / screens / devices could be advantageous to consumers and validation of products for procurement.

11. Should this be done as a representative sample of views a la WCAG EM processes and be left to the writers of conformance documents?

12. The term Web Views is also used in the wild, https://developer.apple.com/design/human-interface-guidelines/web-views

13. Are we restricting views to be narrow or would you include WebViews (web browser embedded within an app, allowing it to display web content) a "view" that is applicable to web and WCAG 3.0 without going into WCAG2ICT does it apply analysis? The only instance of Web View I see on WCAG2ICT and WCAG2Mobile is within 1.4.12.

Feel free to move these topics to other discussions or respond to what is worthwhile as you see fit.

[GreggVan]

Great list

One comment though. We are spending a lot of time asking about apps that are not web content. The rules for web content are not the same as for software and there are additional provisions for software as well as all the closed functionality issues.

If we are going to talk about anything other than web content we need to

1. break the guidelines into different sections (like EN 301 549 does) for
   • Web content,
   • non-web content and
   • non-web software
2. beef up our team on the non-web software aspects
3. add all the other provisions that apply to non-web software (but not web-software, where there is a user agent) to section 3

The above list combines the 3 types in one list and asks some questions that have different answers for different sections.

So good list - but we need to say what we are talking about before we answer some of them.

and we need to ( as a working group - and in our charter) decide how many different types of ICT we are going to cover. (note that there are 308 provisions in EN 301 549 when trying to cover all three.)

[ChrisLoiselle]

Thanks. Yes, work in progress for my list. Yes, it is heavy on non web and native per what I listed, however we have task forces trying to fit in to a cog in the wheel of WCAG when it would be great to define techniques and design principles for those vs. whether or not they apply to WCAG, i.e. W3C perhaps comes at WCAG 3.0 in terms of ICT > then web content then non-web content, then non-web documents. Ultimately, people want to design, develop and validate for accessibility and overall use as well as conformance to the standards. Thanks for reading Gregg!

[GreggVan]

@ChrisLoiselle It would be helpful to divide your list into different categories -- web vs nw-apps vs nw-docs vs "applies to all three". It would help.