– DRAFT –
AGWG Teleconference

alastairc: Welcome, is anyone new or wanted to introduce themselves? No announcements today.

Sub-group check-in (what's the status), and questions/answers

alastairc: start off with the first agenda item

alastairc: Sub group check in
… we haven't done it in a while, idea is that someone from each group could give us an update
… current progress, any blockers or challenges
… if there are any issues that are common across groups, we can spend time trying to unblock those

<Zakim> Chuck, you wanted to provide help and errors update

Makoto: Almost done with two guidelines, captions and audio description
… had a question about template
… will the template be updated?
… we are working with the current one, but can adjust if needed
… we'll start working on the guideline for text alternatives for images next

alastairc: Thanks, visual appearance?
… it's been a few weeks since I've been able to join, but we were close to wrapping up text appearance aside from i18n considerations
… we were working on reflow and density, and out of the requirements for WCAG 3, we're about half way
… or 1/3, no particular blockers at the moment.
… plain language, consistency, familiarity?

julierawe: Question about visual appearnace
… I saw on the pathways doc that you wanted feedback on i18n?
… would COGA also be helpful?

<ljoakley> presetn+

alastairc: To be more specific, the i18n help needed is that we have these tables of examples for english, russian, arabic, hindi, we filled in one column, but we need to fill in others
… looking for some values to use as a readability baseline
… need help from people familiar with those languages
… be able to find standards for line-height or other parts of typography
… it is quite detailed i18n work, readability in different scripts/languages

julierawe: Update from plain language, we have two versions of the plain language draft
… we send the two to the AG chairs for feedback
… if we do it in the streamlined way, there wouldn't be a description of the principles, could we use the what to do section of the document to help people understand
… we're hoping to get some feedback from the chairs, which direction we should go in
… do people need to go elsewhere or structure the what to do with the explanation built in
… this week we are working on the rest of the items in our path

alastairc: I saw the email, we'll get back to you
… organizational structure

giacomo-petri: We are working on the methods
… while doing this we were wondering about lists, trees and menu items or options in a dropdown may be perceived as lists
… we worked on including them in the decision tree
… we are progressing

alastairc: Inputs?

<bruce_bailey> https://docs.google.com/document/d/1cxiE1rfpmYs0fmS1CDyRGq-_-_mTghz7vRlGcAhgWLc/

bruce_bailey: Link from our scratchpad
… we've evolved from keyboard only to keyboard, to requirements that touch on input and explore them
… keyboard-only ended up being the mothership of many requirements, we have a composite requirement
… meeting twice a week to clean this up
… getting ready to present

GreggVan: Should we mention they are mostly finished and we're working on the template?

alastairc: The keyboard-only part is done, and there are others?

GreggVan: If you go in, you'll see they are all completed
… we're working on the template
… bruce_bailey do you think it will be ready after today?

bruce_bailey: I'll look forward to the chairs giving us a deadline to work towards
… we're also working on methods and decision trees
… we were able to divide into requirements and sub-requirements, but they've been pretty flat

GreggVan: Question, you told us before to work down to methods, we've gotten them completed down to the methods point, do you want us to do the techniques or just what is going into the draft?

alastairc: If you finish everything, go ahead and do techniques, but it sounds like you'll be good for cross-review soon
… interaction and AT support?
… help, errors, feedback and triggers?

Chuck: We have a fairly solid applicability tree, we contemplated different circumstances that needed to be branched off
… error is not a result of data in single input, what about inputs in relation to each other, like a start/finish date.

<kirkwood> link to help/errors?

Chuck: we have also realized that as we have put the trees together, we came up with terms that helped conceptualize the thoughts, we now need to provide definitions
… the question we have is to the group, is inputs working on the concept from WCAG2 about change of context on input
… error states for data introduced elsewhere, we were concerned that we might be responsible for the change of context on input but we're not proceeding like we're responsible for that
… is there a subgroup handling that concept?

<alastairc> julierawe - had you gone?

GreggVan: The change of context has to do with only if the user requests it, to do with input, I am trying to figure out if it falls under input

alastairc: I can try and help with the question
… we have several requirements for interaction and AT support for context change and such, it might be related

Chuck: Interaction and AT support might handle calling out violations, we don't need to be concerned

alastairc: I don't think so, make a note though

<bruce_bailey> https://docs.google.com/document/d/1cxiE1rfpmYs0fmS1CDyRGq-_-_mTghz7vRlGcAhgWLc/edit?tab=t.1t09ra11jl6v#heading=h.elegnq9r3m1

bruce_bailey: To build on Gregg and Chuck, I added a heading, we planned not to touch hover information, but it's important to keyboard operability, check all areas of the page for popups

<bruce_bailey> Check all areas of the page to see if something pops up or replaces part of the content when the pointer is moved over all elements on the page

bruce_bailey: it's part of our testing algorithms

alastairc: Potentially overlapping?

GreggVan: Is it?

alastairc: There's a couple of requirements around change of requirements or inform before activation, I don't think there's an overlap in the requirements themselves but we'll have to look
… last one is safety and deception

todd: Attendance has been spotty, I've been working on applicability trees for each of our topics, I'll share a link to the document
… not sure if my email is getting through, if you're in the group please checkout the github repo and see if there is anything we can pull out, if not we can move on
… I need a way to effectively communicate that
… my email for W3C may be going into spam folders?

<todd> https://docs.google.com/document/d/1_f3cJ2Wvnv7Q56QDPvGUADE_JQ7HiyOYYREDiaQpPmM/edit?usp=sharing

todd: other than that we're working async, that's all I have for now

alastairc: Motion and motion for help are in the interaction pathway, but not sure how it ended up with you, but maybe for something else

todd: There was possibly some useful info, but nothing I've seen

[crosstalk the scribe missed]

<alastairc> https://docs.google.com/spreadsheets/d/1Ecg9qFIUVCUQfAPgNSEZ8MmsCSjbAynK8hbGBU8NrzQ/edit?gid=2035961492#gid=2035961492

alastairc: Any questions?

Unit and Process definitions https://docs.google.com/document/d/1pN6zc0YjxY2TmhmrSii0Y5ghzjdNOqMV5F4a_Dfqsyo/edit?tab=t.yyfjn0xes91s

alastairc: chairs will discuss the specific questions this week and get back to you
… next item is about the unit and process definitions
… there's been a lot of holidays in the last week
… thought it was worth going through an update

[share screen]

alastairc: I went through everything that was said and added, I focused on the smallest thing and then worked up
… trying not to name these things yet

alastairc: There is potentially value in figuring out the smallest thing we could define
… level one, then groupings of things

alastairc: Control, user interface control, menu
… focusing on the interactive
… then the next level user interface context
… if more than 50% of things change its a new context
… then last level is a process or task, a series of UI contexts or tasks, required to complete an activity from end to end
… last level is product/claim scope
… a set of UI contexts that are part of a conformance claim, similar to WCAG2, if something is part of a process, you must include the process
… we'll provide informative guidance on determining a conformance claim
… a few related definitions
… content, closely available

GreggVan: First, when you talk about 50%, can you change to x%? Allow us to discuss the percentage
… you said associated components, how do we define components

alastairc: A grouping of items to make an interactive component for a distinct function.

GreggVan: Concern I have, what if you do something and all of the text changes
… no interactive components, is it not a change in context if the content changes?
… vs saying number of characters or words

alastairc: Something to worry about in the requirements themselves?

GreggVan: We're defining it here, I'm trying to figure this out, I don't have an answer, there may be an issue in referring to interactive components
… it can't just be interactive, but % might introduce other problems
… above and below may introduce other challenges
… change of UI context may be different, we're possibly mixing the meaning of "context"

alastairc: We haven't used "change of context" in WCAG3 yet

GreggVan: One or the other should get a name change

<Chuck> wendyreid: I'm wondering if we are over-complicating this. These are concepts from user experience design and industrial design. Are there existing definitions that are familiar to industry?

<Chuck> wendyreid: Some use "atomic design". I wonder if there is existing language that is clearly defined and recognize, so that we need not re-invent the wheel, if this is well established industrial standard.

ljoakley: Thank you wendyreid, I was going to make similar comments, web design has been around for a long time, we have terms, I like the unit idea to move into component
… would like to move away from "control", we can control all sorts of things, it applies to many things
… component is a specific piece made up of other pieces
… using unit and component is what I use with my users and it helps people who don't normally do accessibility work
… it helps them understand where the errors are

GreggVan: You might want to note the concern about context so we don't trip on it later
… you talked about name and things with a name
… the characters on a page, are you talking about a programmatic name, we have labels and names
… programmatically determinable name

alastairc: Yes, accessible name

GreggVan: Maybe we want to clarify that, non-programmers may not understand
… other one is you might have covered by the explainer, I want to warn us against trying to create a taxonomy for controls when the only thing that matters is evaluation units
… we need to have a name for the thing below the evaluation unit
… to stick with the stuff we actually have a use for

<Zakim> alastairc, you wanted to comment on familiar vs unique terms

alastairc: wendyreid and ljoakley were talking about people defining these terms before, they tend to define things in varying ways
… if anyone knows of a set of terms that would fit well with WCAG3. I agree with Gregg that we only should use what we need
… I did find it difficult to define the one we need, UI context, without a definition of interactive components
… I've kept it to interactive components, things, it helps if we have a grouping of interactive things like a menu, if you're looking at an interface with various things, more substantial
… it makes the next level up easier to define
… the problem when looking at design systems with atoms and such, we don't want to define each thing
… design systems define everything, like paragraphs, it doesn't quite work in the context of what we're trying to do here

<kirkwood> “ interactive elements”

GreggVan: A good point to make, if the interactive thing is the menu, the order of items in the menu needs to be consistent

<Zakim> alastairc, you wanted to comment on when these can be useful - focus styles

GreggVan: does it have a name, just putting an ! on your point, sometimes we need to look at individual items in the whole

alastairc: We had this in WCAG2, how do we apply focus styles, what size
… for things like a dropdown, it might be that the dropdown has the focus but you're selecting an item with in the dropdown with active style instead of focus
… there's things we could have done in WCAG2 but we had other definitions in place
… focus style had components and sub-components
… if we get the concepts right, the names might get easier

<kirkwood> An interactive component is a reusable, pre-designed UI element with built-in interactions, while interactive elements are any elements that can be interacted with by the user. Essentially, interactive components are a higher-level category of interactive elements, encompassing multiple interactive elements within a single, reusable unit.

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

alastairc: webpage, user interface context, are they included in your requirements, do these definitions help or hinder?

<alastairc> https://github.com/w3c/wcag3/discussions/286#discussioncomment-12670208

alastairc: please pop ideas in the discussion

GreggVan: Question before breakouts, you have us working on the fundamental and supplemental requirements, we're also finding that we might need to organize them differently under guidelines
… inputs might have gesture, but other gesture things in another guideline
… as part of our remit, could they organized differently?

alastairc: As long as its in your pathway, feel free to organize as you wish, but if it crosses into another check with that group
… any other questions before the breakouts?
… please join subgroups!

<ChrisLoiselle> partial regrets for 2nd hour , apologies.