Meeting minutes
<ChrisLoiselle> partial regrets, can only stay until 11:55 am ET (customer meeting)
Subgroup check-in
Chuck: Starting with subgroup checkin. The help errors feedback group finished an applicability tree, now drilling down on methods. We have a new member too
<alastairc> Chuck - could you (or someone in the Help group) update the status column? https://
Frankie: we have reached a point on captions where we have some blocking questions. We are ready for some reviews, how do we go about doing that?
<DJ> Visual Appearance https://
DJ: We just finished text appearance except for i18n concerns, we've moved on to adjustable layout requirements, orientation, reflow
julierawe: Plain language has been working on an assertion and we have asked org structure/cognitive to have a joint meeting to cover overlaps.
giacomo-petri: we have completed our decision tree, now onto methods (Structure cognitive)
bruce_bailey: We are updating focus methods to focus on keyboard focus
Jen_G: We do have a question for the chairs
Chuck: We'll address questions after the subgroup updates
GreggVan: Working on complex pointer input to distinguish fundamental vs. supplemental
hdv: we've been involved in the views discussion, we have had attendance trouble with the weekly meetings
<bruce_bailey> Inputs google doc: https://
Todd: safety and deception, we've been fleshing out the applicability tree and linking definitions to the glossary. We should have our next guideline wrapped up in the next couple of meetings.
Chuck: now let's address the subgroup questions
<Makoto> Captions https://
Frankie: (Image and media alternatives) Question: How will we engage to get reviews? We are looking for feedback on formatting. We also are looking for collaboration from other groups for best practices and alternative method. Another question: how to approach quality measures. How detailed to be, where to put them.
Chuck: I've recorded your questions, they may take more time than we have, but we will address. Are you blocked?
Frankie: no
GreggVan: We defined a new term "Simple pointer input".
<Zakim> alastairc, you wanted to request (after the round-robin) that people update the pathway doc with current status on the requirements worked on and to comment on the quality measures for alternatives
alastairc: subgroups, keep the status spreadsheet updated please.
alastairc: Frankie, when talking about quality measures we have a couple of options. You can do a simple best practice statement or you can make an assertion to bring it into conformance measurement.
<Zakim> Chuck, you wanted to ask the question about the question
<Zakim> bruce_bailey, you wanted to ask about methods
bruce_bailey: we know in inputs that we won't find a robust list of input methods, nothing similar to alt text.
<bruce_bailey> comprehensive method decision tree for keyboard input is not feasible
GreggVan: We have different types of inputs, we have "if this then" provisions, but we don't have a comprehensive tree.
WCAG 2.2 issues https://lists.w3.org/Archives/Public/w3c-wai-gl/2025JanMar/0092.html
alastairc: I think that's fine as long as it makes sense. If you had a requirement that crossed input types you might need a tree. For image alt group, we'll try to get a chair to drop in to do reviews. Any subgroups that need that let the chairs know
Chuck: moving on to WCAG 2.2. issues
<mbgower> https://
mbgower: I sent out a list of changes out right before CSUN, they were mostly "housecleaning" issues. There are a couple of substantive changes that are failure technique recreations. There is a link to the issues here: https://
<bruce_bailey> Project Board requires login
mbgower: (sharing the WCAG 2.X project board) showing that there are labels on the issues that show there relative priority or importance. There are issues with "response-only", we are hoping folks will review and wither thumbs up or comment. We are on a two-week cycle for changes.
UI-context (ex-views) definition
<Chuck> https://
<bruce_bailey> Issue list (public, no GitHub login required): https://
Chuck: Continuing converstion about UI context (definition of views)
alastairc: we discussed this last week. We had a few comments in github, thanks for those. I tried to digest the comments and propose and update. A context is a layout with a set of components. Including components that can be added without making components unavailable. We added "a substantial number of components" becoming unavailable.
alastairc: Trying: components that are not in a consistent place within the layout are considered content. Added dictionary definitions of layout, interface, and components.
GreggVan: This brings up the challenge that if we want our provisions to be testable the unit needs to be agreed upon and objective. "Substantial" creates potential ambiguity
<CarrieH> +present
GreggVan: "Consistent" can also be a problem for objectivity. "Components" how granular should we get when talking about components, components are often made of components.
<bruce_bailey> +1 to hdv for "parts" rather than components
<scott> also +1 to parts. i like that idea
<Zakim> Chuck, you wanted to ask what our goals are for this conversation?
<Zakim> alastairc, you wanted to comment on substantial, and whether removing it makes it more objective? and to ask whether "control" would be better than component?
hdv: I really like the work that happened here. I too worry about the word components because it can mean different things to different people. I wonder if we can use the word "part" in the defintion. I've added a straw-man proposal to this effect. I feel like the statement about components making other components unavailable should be more clear.
Is this adding to the DOM, adding visually?, added to the a11y tree? Let's clarify "added". Asking for people to thumbs up/down these comments proposing changes. Also: not sure about note on failure from content being available only visually or programatically. Maybe we should have a stronger assertion that needs to be avoided.
<hdv> [ the 4 comments I just mentioned are in the doc as comments , if people want to thumb up / down with emoji
alastairc: (looking at examples in the Define views Doc) The W3C.org page has a header/footer/content area. The layout is consistent across pages, so this is one UIC (User interface Component), one unit. However if you go to the WAI site, that has a different layout and is a different UIC. We need to be clear that we need to cover different content
types.
alastairc: Now looking at the iOS mail app. These are four different UICs, there are no shared controls
alastairc: Looking at eBay: this has a homepage, category page, and item page with the same header, we can consider that one conformance unit, but when you drill down you start getting similar pages. We need to give this some thought
alastairc: If we take out "substantial" from the definition does that make the definition less useful because even small changes can cause a change. Would one solution being using "Control" rather than "Component"? There was also a suggestion for "Part" is that too broad? Controls are the important bits in a layout. Does switching to controls make
the defintion more flexible?
<Zakim> GN, you wanted to say that if components change position it also changes context
GN015: As soon as I input into a search field the view changes, this should be a failure. Components changing position should be a failure
<Jon_Avila> I would consider the Ebay pages 3 different pages.
<scott> agreed.
<hdv> +1 to Wendy's point that the people who use/read/process audits are important to consider, that's essential to the goal of achieving more accessibility through WCAG
<kenneth> +1
wendyreid: Who is our audience for the definition? If the audience is an a11y professional trying to work out how to audit with WCAG 3, this definition doesn't necessarily reflect how a company would think about their components. When I audit, I need to cater my audit scope to the ownership of the components. I'll still test how they all work
together, but I'll report on a ownership basis. This may be confusing for internal testers
GreggVan: When you looked at the mail app, I want to be careful to note that there are more contexts like settings. I think the test will be things like a design app with lots of templates coming in and out. If I add something have I changed the context. Also: on "substantial" if we remove it it falls apart if you add it it falls apart. I think
controls is better than "components" but not everything is a control in a layout
<Zakim> hdv, you wanted to comment on control vs component
<Zakim> alastairc, you wanted to say failure is for requirements, not definitions and to say this isn't web-pages, to add reasoning
hdv: I think controls remind me of form controls. I wouldn't think everything in the layout can be divided into controls, parts might work better
<GN015> The definition influences whether a test fails or succeeds.
<Zakim> Chuck, you wanted to react to alastairc to say switching to conversational queueing
alastairc: The definition doesn't determine failures, requirements do. This definition is for scoping requirements and scoping conformance claims. I think this better matches how teams works because you are looking at the templates that are being used. If we take this approach we need a method to capture the different types of content that can
occur in a context. We are also looking at defining product, task, for different levels of contexts. The general idea is that if we take the layout and set of component that are integral to the layout we have the context. If there is a different approach that is more granular that might be another approach
<GN015> There are several Success Criteria which forbid a change of context: the context should remain unchanged on moving the focus, the context should remain unchanged when performing an input.
<Jon_Avila> Seems like have the context across multiple pages would be an issue for criteria that rely on access to alternatives.
<bruce_bailey> +1 to AC that current web page definition is something that must be ignored to get work done!
<Zakim> bruce_bailey, you wanted to suggest somehow combining last two phrases of definition
<ChrisLoiselle> apologies, need to leave for another call. I'll read the minutes.
bruce_bailey: I want to mention that this is a good definition, the thing that stopped me was the last phrase about substantial change.
alastairc: if you have a modal it will get rid of all the other controls, that seems like a reasonable dividing line for context
<Zakim> Chuck, you wanted to ask for a summary of where we are at?
bruce_bailey: if you looked at the source code you may find that the modal was already there in the DOM, so I like this definition, it has. a lot of functionality
<bruce_bailey> i think with model -- and traditional web pages -- view page source will contain the coding for the model
<alastairc> We need the definition to work without a code view. And +1 to gregg comment that we can't rely on the coding method
<GN0157> For parts of the page which remin consistent across several pages we used to talk about parts (for example navigation areas) that repeat on several pages.
<bruce_bailey> concept of "what's under view page source" also covers examples of iOS email (3-4 UI contexts) and eBay (3 UI contents, per Wendy's concern) pages.
GreggVan: Talking about whats embedded in the page is one of the problems. If you can have a case where two things look identical to the user but are coded differently we have a problem. I think UI content needs to be what a person sees. If the "substantial" phrase were to be surgical it would work. If a modal pops up and it covers the old stuff,
clearly this is a new context. Its the non-modal that pops up over the top and covers SOME stuff that is a concern to me. To a screen reader user this covered up stuff may be available, but for other users it may be unavailable, does that create two different UI contexts. And finally "Parts" has the same problem, anything that has parts has parts
of parts, this is still vague.
<Zakim> alastairc, you wanted to provide summary
<Zakim> Jennie_Delisi, you wanted to ask about off screen
Jennie_Delisi: if you consider what is off-screen because the user has changed what they are looking at or they are on a different device that changes the visual context how might that change the context created by visual content or programattic content
hdv: You have everything inside the definition of parts while components might not be all-inclusive. To try a pizza metaphor: if you cut a pizza into parts, everything about the pizza will be in one of the parts. If you take out components or controls, you're maybe taking only specific ingredients/toppings, but not all of the pizza
Task Flows / Processes https://github.com/w3c/wcag3/discussions/294
alastairc: we are trying to keep this conformance unit to things that are available visually. We want to use requirements around things needing to be both programatically AND visually available
Chuck: Check out the task flows conversation on GitHub, please take a look at it. https://