AGWG Teleconference -- 15 Jul 2025

<Chuck> meeting: AGWG-2025-07-15

<Jennie_Delisi> scribe+ Jennie

<Jennie_Delisi> Chuck: We will start in 1-2 minutes

<Jennie_Delisi> Chuck: Welcome.

<Jennie_Delisi> Chuck: Housekeeping - introductions. Anyone new to the group, or has a new role?

<Jennie_Delisi> Charu: I am new. I now am back in as a TPGI member

<Jennie_Delisi> Chuck: 1st meeting of any month this call begins 30 minutes early for an orientation. Anyone is welcome to join.

<Jennie_Delisi> kevin: checking on the identity of someone in the Zoom room

<Jennie_Delisi> Chuck: Announcements

<Jennie_Delisi> ...1: WCAG2ICT will have an update in the next few weeks.

<Jennie_Delisi> ...This will be presented for our review, then CFC, then publication

<Jennie_Delisi> Mary Jo: To align WCAG2ICT and the European regulation.

<Jennie_Delisi> ...Found some language consistency issues we also want to address.

<Jennie_Delisi> ...This will provide a document which can be referenced in the EN standard

<Jennie_Delisi> ...There are 4-5 issues left to work through

<Jennie_Delisi> ...This will make a version showing a dif ready for your review

<Jennie_Delisi> Chuck: Next announcement: scheduling approach conversation

<bbailey> https://github.com/w3c/wcag2ict/issues

<Jennie_Delisi> ...Survey - concerns expressed that information may not have been accurate

<Jennie_Delisi> ...Chairs want to present an accurate view of the options for everyone to consider.

<Chuck> https://github.com/w3c/wcag3/discussions/343

<Jennie_Delisi> ...A discussion was opened this morning.

<Jennie_Delisi> ...Intent: participate in the discussion, then in the next call it will be an agenda item.

<Jennie_Delisi> ...Any other announcements from chairs?

Terminology https://github.com/w3c/wcag3/discussions/286#discussioncomment-13630186

<Jennie_Delisi> Chuck: Previous discussion was robust, but no decisions at that time.

<Jennie_Delisi> ...Asynchronous conversations happened

<Jennie_Delisi> Alastairc: We have a set of definitions to do with how we define scope or conformance.

<Jennie_Delisi> ...Started with element types, groups...

<Jennie_Delisi> ...Since last time people are happier with interactive group.

<Jennie_Delisi> ...We got through how a menu figures into this.

<Jennie_Delisi> ...We got to 2 potential conformance units.

<Jennie_Delisi> ...1: a page, similar to WCAG 2 version. And if you can use this, use it.

<Jennie_Delisi> ...For things where you cannot use that scope we have a few versions, which we have not agreed on

<Jennie_Delisi> ...Goal: we have this interface in front of us (visually and programmatically available) until something happens

<Jennie_Delisi> ...Challenge: in-between cases like things that expand, or take over (like a modal).

<Jennie_Delisi> ...We discussed concepts like "thin-slicing" like bread - how thick. The product is the loaf of bread.

<Jennie_Delisi> ...How thick do you slice it?

<Jennie_Delisi> ...Considerations: thin slice has lots of items which you check for conformance.

<Jennie_Delisi> ...For a "thick slice" you have more significant changes considered as part of a new view

<Jennie_Delisi> ...For example going through tabs would be considered part of the same view.

<Jennie_Delisi> ...In discussions since last meeting: we came up to challenges finishing statements included in the document.

<Jennie_Delisi> ...There are good ideas, and need to refine and discuss.

<Jennie_Delisi> ...Today: can we agree to the other definitions?

<Jennie_Delisi> ...Can we agree to the 2 conformance units?

<Jennie_Delisi> ...Can we get to a good definition of view that doesn't trigger objections?

<Jennie_Delisi> Gregg: All my questions about level look good now.

<Jennie_Delisi> ...This solves the question about interactivity.

<Jennie_Delisi> ...Definitions - the suggestion at the bottom I cannot poke holes in at this time.

<Jennie_Delisi> ...I think it will be helpful to take the last suggestion and run some examples by it.

<Jennie_Delisi> ...The previous ones: if I have a website and if there are tabs at the top, the entire website is included.

<Jennie_Delisi> ...The last suggestion seems to avoid this issue.

<Jennie_Delisi> Hidde: I think the concept of having multiple conformance units will work well.

<Rachael> +1 to multiple conformance units

<Jennie_Delisi> ...I also think the other definitions work well now.

<Jennie_Delisi> ...For the suggestion: this is the first time I have seen it, so need processing time, but I like what I see now.

<Jennie_Delisi> ...I agree, the examples will help.

<Jennie_Delisi> Alastairc: A particular chunk of content does not seem like appropriate text. We need to refine that.

<Jennie_Delisi> Gregg: We still may have something missing - set of pages, or conformance claim, or process.

<Jennie_Delisi> Alastairc: we need to get the pages, view. We have the others.

<Jennie_Delisi> Gregg: When we have a consistency (process if you want to get bigger) then modal dialog isn't going to make sense.

<Jennie_Delisi> ...Consistency needs to be broader than view, probably broader than page.

<Jennie_Delisi> ...I think this is powerful - allows us to get broader or narrower. Good progress.

<Zakim> Chuck, you wanted to ask about the other terms and definitions to see if we can resolve those.

<Jennie_Delisi> Chuck: Sounds like the view is something we can work on refining.

<Jennie_Delisi> ...I would like to invite everyone to think about the other terms.

<alastairc> From this tab: https://docs.google.com/document/d/1pN6zc0YjxY2TmhmrSii0Y5ghzjdNOqMV5F4a_Dfqsyo/edit?tab=t.wzd5xkr7i84w

<Jennie_Delisi> Gregg: The component and component group - we should reflect in the group. Is it too late to incorporate into ours?

<alastairc> Terms: Non-interactive element, interactive element, interactive group, page, view, process, conformance scope.

<Jennie_Delisi> ...Into the keyboard subgroup

<Zakim> mbgower, you wanted to say fine with having a split on our large building blocks (page and view). I think "fills the viewport" is a little problematic

<Jennie_Delisi> Mbgower: I have not checked in yet with Mary Jo - I think this makes sense.

<Jennie_Delisi> ...Fills the viewport might be problematic, but this might be the next stage.

<Jennie_Delisi> kevin: Re Gregg's question

<Jennie_Delisi> ...If you can do it quickly, yes. That would be welcome.

<Jennie_Delisi> ...Suggestion: put it in the PR - makes it easier to capture the changes.

<Jennie_Delisi> ...the pull request for your work.

<Jennie_Delisi> ...Please put it here instead of the Google Docs.

<Jennie_Delisi> ...Francis should be able to do that.

<Zakim> alastairc, you wanted to comment on intergrating

<Jennie_Delisi> Alastairc: Make sure the changes are recognizable for Francis.

<Jennie_Delisi> ...Because the definitions are going in in parallel, we will do an editorial pass.

<Zakim> ChrisLoiselle, you wanted to comment on where functional images fit in

<Jennie_Delisi> Chris: re defined views. Will functional images be interactive?

<Jennie_Delisi> Alastairc: an image that is made interactive I would consider it within the interactive element.

<Jennie_Delisi> ...Any element can be made interactive if it responds to user input.

<Jennie_Delisi> ...If wrapped in a link or button - this would be an interactive element.

<Jennie_Delisi> Chris: that makes sense.

<Jennie_Delisi> ...Re the word "view"

<Jennie_Delisi> ...Re issue 286

<Jennie_Delisi> ...Landscape and portrait views - separate? Or view within a view?

<Jennie_Delisi> ...Example: on a mobile device, browser open.

<Jennie_Delisi> Alastairc: good question. The definitions need to be robust about change.

<Jennie_Delisi> ...It should carry on working.

<Jennie_Delisi> ...If you have a web app that is presented in portrait with a particular interface, then you change to landscape

<Jennie_Delisi> ...If content is added or removed, this could be a new view.

<Jennie_Delisi> ...If it replaces content it becomes a new view - so depends on what happens when you change

<Jennie_Delisi> LoriO: I need to read through this carefully before coming up with suggestions.

<alastairc> Terms: Non-interactive element, interactive element, interactive group, page, process, conformance scope.

<Jennie_Delisi> AlastairC: in the document I delete terms and use the items listed above.

<Jennie_Delisi> ...These are either ones people are happy with, are non-contraversial.

<Jennie_Delisi> ...We could have a resolution related to those.

<Jennie_Delisi> ...The process one is close to the WCAG 2 one (reads from the document)

<Jennie_Delisi> ...there is a section which is new

<Jennie_Delisi> ...To me: whether it is "under the control of the provider" is different than the WCAG 2 version

<Jennie_Delisi> ...This becomes more technical.

<Jennie_Delisi> ...The last one: conformance scope (reads from the document)

<Jennie_Delisi> ...This is similar to the conformance scope in WCAG 2

<Jennie_Delisi> ...Gundula mentioned if you are going across a process this might not be under the control of the same entity

<Jennie_Delisi> ...Example: going across different products.

<Jennie_Delisi> ...In the case of process do we want to embed that the entire process is under control of the provider?

<Zakim> bbailey, you wanted to ask why provider better than author (or page owner)

<Jennie_Delisi> Bruce: We have had some questions about author, but provider seems even more vague. What are the advantages?

<kevin> +1 to vagueness of "provider"

<Jennie_Delisi> ...Page owner, page controller

<Jennie_Delisi> Chris: When I hear that phrasing it brings up target content, and who is responsible for what

<LoriO> Bruce +!

<Jennie_Delisi> ...Clarifying would be helpful

<Jennie_Delisi> ...3rd party content, author, and how it scaffolds

<Zakim> alastairc, you wanted to answer Bruce - provider

<todd> +1 also to "provider" being vague

<Jennie_Delisi> AlastairC: not sure where provider came from.

<Jennie_Delisi> ...I am not sure that author is a good term, but don't have a better one.

<bbailey> i agree "author" is imperfect

<Jennie_Delisi> ...The more neutral we can make the definitions the easier it will be to scale and scope

<Jennie_Delisi> Lori: +1 to Bruce.

<Jennie_Delisi> ...I dislike "provider"

<ChrisLoiselle> for reference https://www.w3.org/TR/WCAG22/#conformance-partial and third party

<Jennie_Delisi> ...Page aggregators - a framework page which gathers news from different sources

<Jennie_Delisi> ...Who is the provider there?

<Jennie_Delisi> ...When AI puts it on the framework page...

<bbailey> provider seems like is creates more loopholes than it closes

<Jennie_Delisi> ...You can have news from 1000s of different providers.

<Jennie_Delisi> ...Provider is probably not the best word to use.

<Jennie_Delisi> ...Maybe the webpage author might be more accurate.

<Jennie_Delisi> kevin: I am hesitant to put something like this.

<Jennie_Delisi> ...It gets into the policy space.

<Jennie_Delisi> ...Some policies define what to do with 3rd party content.

<ChrisLoiselle> Lori, I think https://www.w3.org/TR/WCAG22/#conformance-partial covers what you were mentioning

<Jennie_Delisi> ...If the web page is conformant or not conformant, it is immaterial

<Jennie_Delisi> ...What is relevant is does it meet the requirements of the standard.

<Jennie_Delisi> ...From a compliance or policy point of view - then the 3rd party piece comes into play

<Zakim> alastairc, you wanted to propose removing that clause

<Jennie_Delisi> ...I think we should stay clear of whether or not it is under control of the owner.

<Jennie_Delisi> Alastairc: does anyone object to removing that?

<Jennie_Delisi> Hidde: I agree with removing it.

<todd> +1 to removing

<Adam_Page> +1 to removing

<LenB> +1 to removing

<Jennie_Delisi> ...It could also be in a non-normative document.

<LoriO> +1 to removing

<bbailey> +1 deleting phrase highlighted (removing provider)

<kevin> +1 to being expanded on in non-normative document

+1 to removing

<LTSzivos> +1 to removing

<Jennie_Delisi> Chuck: Anyone object to removing it?

<Charu> +1

<ShawnT> +1

<Makoto> +1

<Jennie_Delisi> ...Nobody is objecting to removing it

<Laura_Carlson> +1

<Jennie_Delisi> Alastairc: for conformance scope.

<Jennie_Delisi> ...Gundula's question: if making a conformance claim, and defining a set of pages

<Jennie_Delisi> ...Should we do the WCAG 2 approach

<Jennie_Delisi> ...and include the other pages/views.

<Jennie_Delisi> ...Anytime you include 1 page from a process you need to include all the pages in the process.

<Jennie_Delisi> Gregg: Do you want to remove it or keep it?

<Jennie_Delisi> Alastairc: we are suggesting keeping it.

<Jennie_Delisi> ...She is suggesting removing it.

<Jennie_Delisi> Gregg: You cannot claim something is accessible if the rest of the process is not.

<Jennie_Delisi> Chuck: I am opposed to removing it.

<Jennie_Delisi> ...chair hat off.

<Jennie_Delisi> Chris: On the conformance - where a view or page...(reading from the document)

<Jennie_Delisi> ...If you are interacting with a page, a modal is launched

<Jennie_Delisi> ...This becomes a view within the page

<Jennie_Delisi> ...You then interact with that view - is that part of the process or separate but related?

<Jennie_Delisi> ...In terms of conformance.

<Jennie_Delisi> Alastairc: Because it is needed to complete the process, yes.

<bbailey> +1 to keep it, but has minor conflict with CAV

<Jennie_Delisi> Chris: I think it works but the definition you just gave, it may be more clear up front to make the differentiation.

<Jennie_Delisi> Giacomo: I think sometimes the modals potentially open a new process.

<alastairc> bbailey - CAV?

<Jennie_Delisi> ...On websites you have a link in the top navigation, but still have the old flow in the background

<Jennie_Delisi> ...In this case: is the home page part of the process or something different?

<Jennie_Delisi> Alastairc: good question.

<Jennie_Delisi> ...If using the web page definition for home page, and the URL doesn't change when opening the store locator, it is part of the same page.

<Jennie_Delisi> ...If modal, the starting point could be different

<Jennie_Delisi> ...That is a case where you could go either way depending on the type of interaction you have

<Jennie_Delisi> ...As long as it is not ambiguous it is ok, even if the answer is different.

<Jennie_Delisi> Chuck: People seem supportive of leaving it in.

<Jennie_Delisi> Bruce: I have a little concern about the conformance scope language

<Jennie_Delisi> ...people may have some concern

<Jennie_Delisi> ...We may need to strengthen it

<Jennie_Delisi> Alastairc: Claiming conformance is more difficult if using conformance alternatives

<Jennie_Delisi> Bruce: Because it is all the views in the process

<Jennie_Delisi> ...All pages in the site includes inaccessible pages for which you provided alternate versions

<Jennie_Delisi> ...But the conformance statement says it must be all pages in the site.

<Jennie_Delisi> Alastair: similar to WCAG 2 - it is self-selected

<Jennie_Delisi> ...If you include one part of the process you need to include all parts of the process.

<Jennie_Delisi> Chris: Responding to Giacomo

<Jennie_Delisi> ...If I am on a shopping site, URL page

<Jennie_Delisi> ...I load a modal for inventory

<Jennie_Delisi> ...local to me

<Jennie_Delisi> ...The page changes, and I am now looking at something local to me

<Jennie_Delisi> ...The store locator example - it is a page, part of a process, now part of a view

<Jennie_Delisi> ...I am looking at a set of pages

<Jennie_Delisi> ...In the eyes of WCAG 3 - are we talking about the subsequent pages or are they all considered part of the original page load

<Jennie_Delisi> ?

<Jennie_Delisi> Alastairc: If you are making a conformance claim you are selecting the pages

<Jennie_Delisi> ...If the URL changes, it is up to you if you are selecting them as part of the conformance scope

<Jennie_Delisi> ...Maybe to make it easier

<Jennie_Delisi> ...If you have URLs and they change, and the URLs are useful, use the page definition

<Jennie_Delisi> ...The option to use the other option is there but we are steering people to page.

<Jennie_Delisi> ...It is a fallback definition of "view" to enable something to be more consistent when they cannot use page.

<Jennie_Delisi> Chris: I need to think about it.

<Jennie_Delisi> ...In theory this helps

<Jennie_Delisi> Chuck: Any other comments we need to discuss?

<Chuck> draft RESOLUTION: Move terms "Non-interactive element, interactive element, interactive group, page, process, conformance scope" from exploratory to developing

<Jennie_Delisi> AlastairC: 1st resolution - all the terms except view

<alastairc> Terms: Non-interactive element, interactive element, interactive group, page, process, conformance scope.

<alastairc> +1

<bbailey> +1

<mike_beganyi> +1

<BrianE> +1

<LTSzivos> +1

<Graham> +1

<todd> +1

<ChrisLoiselle> +1

<GreggVan> +1

<filippo-zorzi> +1

<ShawnT> +1

<LenB> +1

<Rachael> +1

<giacomo-petri> +1

<Makoto> +1

<julierawe> +1

<Frankie> +1

<tiffanyburtin> +1

<mfairchild> +1

<Laura_Carlson> +1

<Charu> +1

<Francis_Storr> +1

<Jennie_Delisi> Chuck: any reservations or concerns?

<Jennie_Delisi> Gregg: we use in some but have not defined view.

<Adam_Page> +1

RESOLUTION: Move terms "Non-interactive element, interactive element, interactive group, page, process, conformance scope" from exploratory to developing

<bbailey> subgroups got extra time last week

<Jennie_Delisi> Chuck: (quick point of order discussion to decide how best to use the remaining time)

<Jennie_Delisi> Gregg: When you talk about views and viewport

<Jennie_Delisi> ...helpful to have on the page

<Jennie_Delisi> Alastairc: We have a definition, which is slightly abstract, but is the simplest we could get to

<Jennie_Delisi> Gregg: The information in the note is helpful.

<Jennie_Delisi> Alastairc: We can link to it.

<Jennie_Delisi> Gregg: I recommend actually pasting it

<CarrieH> yeah, I don't hear viewport as a term frequently..

<Jennie_Delisi> Chuck: (reads Carrie's comment)

I hear it a lot (but work with CSS devs a lot)

<Jennie_Delisi> Gregg: I have heard it a lot but was never sure what people meant.

<alastairc> https://docs.google.com/document/d/1pN6zc0YjxY2TmhmrSii0Y5ghzjdNOqMV5F4a_Dfqsyo/edit?tab=t.wzd5xkr7i84w

<mbgower> It is a very common phrase in my experience

<Jennie_Delisi> Alastairc: Latest suggestion seems well accepted

<bbailey> [link is to glossary]

<Jennie_Delisi> ...Any concerns?

<Jennie_Delisi> Mbgower: I think there is a problem - it is unclear if it is the set of content or the area underneath.

<Chuck> qq+ to change scribe

<Jennie_Delisi> ...And, "fills the viewport" - does that refer to ?

<Chuck> ack

<scribe> scribe: hdv

<Chuck> scribe+ chuck

<Zakim> Chuck, you wanted to react to mbgower to change scribe

<Chuck> mbgower: Somebody put comment in parenthesis, I think we want to take out the word "either". do we even need "available"? A set of content that fills the viewport... <reading...>

<Chuck> alastair: where you have something like a modal that renders content, you have various kinds of popup.

<Chuck> mbgower: Try taking the stuff out of parenthesis. Put it in the next sentence. That's my suggestions. Then the comma can go after viewport.

<Chuck> alastair: doesn't work....

<Chuck> mbgower: Is innert relevant?

<Chuck> mbgower: This is trying to cover a lightbox effect. This is not necessarily inert. There's a lot of things getting piled on top of eachother here. I don't think they are going to be correct. For instance, a tear sheet, opens a tooltip on top.

<Chuck> mbgower: What happens in that situation?

<Chuck> ack hdv.

<Chuck> hdv: I was also thinking we might not need the inert part. I'm not sure what you have is clear. I was thinking "extended" s/b "expanded"?

<Chuck> hdv: And the other ways to get content into the viewport. Not familiar with VR, maybe there are different ways that use scrolling or padding. That may be helpful. This seems reasonable to me.

<mbgower> New messages

<mbgower> 09:03 * Zakim mbgower, you typed too many words without commas; I suspect you forgot

<scribe> scribe: hdv

<Zakim> alastairc, you wanted to comment on modals and what it means

<Zakim> GreggVan, you wanted to say ""is included by expansion and (or renders other content in the viewport unavailable)

GreggVan: I think I like the parenthentical `inert`, adding it to the end doesn't help.
... being brought on top of it… we'd have to say 'while leaving the rest active', because otherwise you bring it on top and render the rest of it inert, or you bring it on top and leave it active, in which case it is still 'part of it'

<Zakim> mbgower, you wanted to say do we have "a set of content" defined? Why not just "Content that fills..."

mbgower: could 'set of content' not just be 'content'?

<Zakim> bbailey, you wanted to say i like where we are going, but is inert in the view or not ?

bbailey: I think the lightbox example is important

<CarrieH> the "insert" wording bugs me, what actually happens when it's "insert"?

GreggVan: I think if we're working towards understanding… adding the bit about inert at the front doesn't make it clearer

<Chuck> +1 to Gregg's observation that "content that renders content..." is confusing.

<Adam_Page> exposed?

GreggVan: when you pop up a modal dialog, visually the rest of the stuff is still there, but it's gone from the accessibility tree
... it cannot be interacted with

alastairc: +1 to not starting with the caveat, let's try a middle version

CarrieH: the word 'inert' is bothering me, it doesn't really make sense to me

<kevin> +1 to 'inert' seeming peculiar

<alastairc> alternatives to "intert"

inert concept is explained in the in HTML spec: https://html.spec.whatwg.org/dev/interaction.html#inert

<alastairc> alternatives to "inert"?

mbgower: the first point covers the main area… what other scenarios are we trying to cover with this and the edge cases?
... in modals, part of the area is grayed out, the bit that is 'inert'… so that doesn't entirely fill the viewport, as a feature, it tells the user which part is not available to interact with

bbailey: considering a lightbox… the content that is inside the lightbox is part of the view…
... so not sure if equivalent

<Zakim> hdv, you wanted to respond to modal not fully filling

<Chuck> hdv: I just added a link to the chat, a definition for inert. I want to add to Mike's point. In Modal overlays, there is a black-greyish area, and I consider this part of the viewport.

<ChrisLoiselle> viewport - visible area of a web page within the browser window or the screen of the device being used. This visible area will vary depending on the device and its screen size, playing a crucial role in how web content is displayed and interacted with. Depending on your viewport (HTML and CSS) you'd have different "views" per what is presented.

<Chuck> hdv: You can hardless see it but you can't do anything with it. That's part of the viewport. In css and html, the dialog element allows you to have it. If you open in dev tools, it tells you that's the viewport.

<Chuck> hdv: You can also change color.

<Zakim> alastairc, you wanted to say the inert is opposite of active.

alastairc: in response to Bruce… inert is kind of the opposite of active in our definition

<Zakim> GreggVan, you wanted to say "The content that a user can manipulate or act on in a viewport including that can be scrolled or panned to, and any additional content that is

<ChrisLoiselle> inert could be changed to no longer able to be interacted with

GreggVan: I try to get away from the exception in my latest suggestion

<alastairc> +1 to V3

<CarrieH> +1 to what ChristLoiselle just mentioned

<Zakim> joryc, you wanted to say that "inert" may be too specific to the HTML attribute

<CarrieH> +1 to V3

joryc: I like the word inert, becasue it is how we talk about it when we talk about the web. But caution that when we define it, to make it clear we're not exclusive meaning the inert attribute but also things outside of it

<bbailey> We agree that content rendered inert is part of the view.

<Zakim> hdv, you wanted to ask about noninteractive content

+1 to joryc 's point

<kenneth> +1 to V3, from the perspective that I was having trouble parsing the whole 2nd half of the earlier versions

<mbgower> +1 to Hidde. that was my concern too. Taking myself off queue

<bbailey> We agree that content rendered inert [remains] part of the view.

<ChrisLoiselle> fyi https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

<ChrisLoiselle> A dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.

<Chuck> hdv: I like Gregg's suggestion (v3), the content that the user can manipulate or acted on, there's probably content that we care about that you can't manipulate or act on. It could be a 1.3.1 violation, headings are still an important part of the viewport.

<ChrisLoiselle> we should not try to define defined terms elsewhere

GreggVan: I'd caution against using the word inert if that is an attribute as we're taking that and then redefining it
... I didn't understand the point about headings, hdv. Or do you mean what if only read it?

<Zakim> just, you wanted to add in my comment on inert per the above copy and paste I made

GreggVan: the same phrase should be at the top and the bottom

<Zakim> alastairc, you wanted to add "consume"

GreggVan: we could define 'actively available' as 'read it, manipulate it, act on'

+1 to GreggVan

<mbgower> V3 is starting to look pretty solid!

<Zakim> kevin, you wanted to respond to Gregg's point

alastairc: yup think actively available can work

kevin: the definition in HTML that Hidde pointed to talks about inert subtrees and the inert attribute, two separate things defined in the HTML spec

<Zakim> hdv, you wanted to ask can we not use it exactly as it is defined?

<Chuck> hdv: Gonna talk about same thing. I think we can use exactly as defined in HTML. Maybe the point is moot, if we move away from "inert". Across the web platform, there is agreement on what that word means.

<mbgower> The content available visually and programmatically in a viewport...

<Zakim> mbgower, you wanted to say remove "actively"?

mbgower: wanted to suggest to remove 'actively' and add 'visually and programmatically'
... but then what if it isn't available programmatically but is available visually?
... maybe something about both things expected

alastairc: in that case it's probably going to fail some provisions we have today

GreggVan: if it is rendered on the screen, maybe it's in the DOM and therefore programmatically available, but it could be offscreen etc

<Zakim> joryc, you wanted to say I don't like "inactive" because it sounds like we are only disabling active controls versus making all of the content available. Suggest "unavailable"

<alastairc> joryc - is "inactive" in V3?

<mbgower> If we've got 1.3.1 (or equivalent) in place, it might be a disservice to put in "visually and programmatically". I'm a little concerned we're making an exclusion zone with that phrase in the definition.

joryc: re the note that we're currently added… 'active' is also currently used in HTML/CSS, like there's an :active pseudo… and looks like we don't mean exactly the same. Available / not available is probably safer

<Zakim> bbailey, you wanted to say "while leaving the rest actively available" is still not clear

joryc: and more suitable for what we're trying to describe her

<mbgower> (i.e., if something isn't available visually, it's not in the view; if something isn't available programmatically, it's not in the view). If we just say "available" our other requirements should cover our butts?

bbailey: I think there's something not grammatically correct here

<alastairc> The content available in a viewport (both visually and programmatically)...

GreggVan: there were some words missing, does this help?

bbailey: my difficulty with the phrasing is where the 'while' refers to

GreggVan: there was a comma missing

GreggVan adds comma

<Adam_Page> +q to suggest “and any additional non-modal content” for V3

GreggVan: anything that is visually available is going to be programmatically available tomorrow
... because future assistive technology will be able to use vision to make everything available

Chuck: point of order, we seem to be on the verge of a breakthrough, so will let this continue

mbgower: I'd remove 'both visually and programmatically' from all of the definition, because we'll have that covered in other places already
... if you have something on top of something the stuff underneath isn't really visually available anymore
... it's all just available
... in whatever way it is available

<Zakim> Adam_Page, you wanted to suggest “and any additional non-modal content” for V3

mbgower: and I don't know what 'actively' means so we'd have to define

<mbgower> what's wrong with just "available"?

Adam_Page: wanted to suggest 'any any additional non-modal content'

<Zakim> bbailey, you wanted to ask the rest of what? Rest of the view? Rest of the viewport?

Adam_Page: the bit where we say 'included by expansion or brought up on top of it' doesn't seem right, it could just be 'made available' as the way it is made available could be in any way, not necessarily on top

<Zakim> joryc, you wanted to suggest that content under a modal is not necessarily visually unavailable. We may want to remove that aspect of the description, even with the "fully"

<alastairc> The rest of the content

joryc: would recommend removing 'no longer fully visual' part of the note, there's nothing saying that content behind a modal must be less visible, we need to keep visibility to a binary

+1 to joryc, there are modals without any gray-ish layer (hard to discover the modality that way but it exists)

ChrisLoiselle: when we say 'content that fills the viewport' , are you stating the viewport is the visible area of a web page or is it broader than that?

<alastairc> mbgower - there's a separate definition for that, and I can see the point of "actively" as modals leave some content visually available when it isn't active.

GreggVan: the reason that 'actively' is added is that we can't redefine 'available' as it is a dictionary term
... the thing about web content is… the viewport varies in size and shape depending on the machine you are on

<Adam_Page> +1 to hdv and joryc, I often see “drawer” UI patterns that don’t visually diminish the rest of the page (e.g., gray tint) but do have proper modal behavior

GreggVan: but because we included anything that can be scrolled/panned it works

ChrisLoiselle: there could be different viewport, but thhe content itself could be a page or a view

<mbgower> (btw, in wcag 2.x inactive content are excepted for contrast requirements, etc. If we don't use "inactive" (or whatever we use as the defined term in WCAG 3), then that content would still need to meet all requirements, which is going to cause intentional use of obscuring through lightbox effects. So "inactive" is important to include in the modal

<mbgower> note.

[ side comment viewport is defined in CSS, but distinguishes between 'visual viewport' and 'layout viewport' https://drafts.csswg.org/cssom-view/#visual-viewport]

GreggVan: part of the viewport is used up by the browser

<Zakim> alastairc, you wanted to comment on "view" being included in "view", shouldn't it be content?

alastairc: Gregg, do we mean the least occurance of 'view' to be 'content'

<Zakim> mbgower, you wanted to say I'd be cautious with "actively available"

mbgower: this maybe has to do with transitioning between WCAG 2 and 3, is that 'available' means not inactive. We kind of flip things here by introducing actively available

<ChrisLoiselle> +1 to MGower, my other comment was on inert vs. active

<ChrisLoiselle> From APG on dialog - dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.

GreggVan: if you talk about a web page, people will assume it is active unless it is called inactive
... would not have to add it all over the place

<Zakim> bbailey, you wanted to say I do not see what work "while leaving the rest of the content in the viewport actively available" is doing.

GreggVan: we can't add exceptions to the definition in a note

<Zakim> mbgower, you wanted to say "by expansion" seems unnecessarily specific

alastairc: if we don't differentiate between expanded content and not we'd leave a gap

mbgower: I'm worried we're making it overly complex with the word 'expand'… a tooltip or an error message appearing, aren't really expanding, like, say, accordions are, but they are added.
... we could list what it is we're worried about and then work the definition around that

GreggVan: an error message would be part of a new view if modal and otherwise it would not

<julierawe> Logging off with thanks to all of you who are digging into the details of these definitions!

<Adam_Page> +1 to mbgower: would be good to choose a word that covers expanding, inserting, etc. — I like “could be revealed” or “could be exposed”

<Zakim> joryc, you wanted to agree with Mike and note that "expansion" has meaning in ARIA

joryc: wanted to +1 that I don't like 'included by expansion' because expansion has a particular meaning on the web and in ARIA, eg see aria-expanded. Maybe just 'newly added' instead of additional content… but I don't think we need to define the means by which the content was added

<Zakim> mbgower, you wanted to say what do we NOT want including in "additional content"?

mbgower: to build on that, can anyone explain what additional content we want to exclude? is there a case we're trying to prevent with that? can't we just say 'any additional content', what are we making to broad?

GreggVan: modal dialogs

mbgower: but we already have the wording there to say modal dialogs

GreggVan: but can't be in a note

<Zakim> alastairc, you wanted to say that we need to be careful about removal of content as well

alastairc: we should consider certain components that can expand and collapse, does collapsing make it a new view?

GreggVan: one of the reasons we would want a modal to be separate, if you're in a screenreader and suddenly the rest of the page disappeared, you're like, where am I, where did it go, you've jumped into a new context

<Chuck> qA?

<Zakim> mbgower, you wanted to say do we even need additional content?

mbgower: we may not even need 'additional content'
... would we lose anything removing 'and any additional content that is included by expansion'?
... my second question: let's consider, what makes this different from page, what are we trying to distinguish exactly? might help with our definition

alastairc: we need some way to talk about change

<Zakim> Chuck, you wanted to say I don't understand alastair's suggested resolution.

<ChrisLoiselle> need to drop , thanks all!

alastairc: what we're trying to do with 'view', we need a fallback definition for when we can't use 'page'

<alastairc> We've moved from a % of content available defining view, to a type of interaction changing view.

GreggVan: people could say… if I expand a paragraph… that's not the same content anymore so is it the same view…? what if you added a toolbar? that answers the big questions around view, if we don't mention expanding content as not changing the view, we'd end up with a lot of views

<Zakim> bbailey, you wanted to say it reads circularly

<Chuck> qq+ to say point of order

bbailey: it still seems circular to me
... a lightbox does change the view, that's not clear from what we have here

<alastairc> it's defined by not making other content unavailable.

<Chuck> draft RESOLUTION: Move the view definition to "developing" for the draft.

<bbailey> i am okay with going forward

<bbailey> +1

<mbgower> +1

<GreggVan> +1

<Adam_Page> +1

<alastairc> +1

<ShawnT> +1

<filippo-zorzi> +1

<LenB> +1

<Laura_Carlson> +1

<CarrieH> +1

<Francis_Storr> +1

<joryc> +1

RESOLUTION: Move the view definition to "developing" for the draft.

Assertions discussion https://github.com/w3c/wcag3/discussions/106#discussioncomment-13357126

<Chuck> "We have been discussing assertions at https://github.com/w3c/wcag3/discussions/106. Based on these discussions, chairs have drafted PR 342 (https://github.com/w3c/wcag3/pull/342). The preview is at https://github.com/w3c/wcag3/pull/342".

Chuck: this is an intro to the assertions discussion
... we'd like everyone to review the PR
... please come prepared next week to discuss any changes you'd like to see to the assertions conversation next week

<alastairc> Preview: https://deploy-preview-342--wcag3.netlify.app/explainer/#assertions

- DRAFT -

AGWG Teleconference

15 Jul 2025

Attendees

Contents

Terminology https://github.com/w3c/wcag3/discussions/286#discussioncomment-13630186

Assertions discussion https://github.com/w3c/wcag3/discussions/106#discussioncomment-13357126

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output